>
> In C variable[0] is essentially a pointer to the start of variable.
>
No, that's plain wrong.
> Also to nickpick even more. memset() expects type unsigned character, and
> uint8_t *, and unsigned char * are not really equivalent . . . which is a
> source of even more errors ;) *This* I've had personal hands on with ;)
>
No, glibc, uclibc, eglibc, even avr-libc all have the same signature, which
is the following:
void *memset(void *s, int c, size_t n);
Also this is the last post from me regarding C stuff, since it's off topic.
> On Tue, Mar 8, 2016 at 7:07 PM, <[email protected] <javascript:>> wrote:
>
>> *Because it's not calling malloc() over and over...*
>>>>
>>>
>>> Yeap, you're right it's calling memset() every loop. Not sure why I was
>>> thinking it was calling malloc() every loop. But the point is, it does not
>>> matter what is being called in the loop. any system / API call in the loop,
>>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as
>>> much as the system will allow it to, which is usually in the mid to high
>>> 90%'s . . .
>>>
>>
>> Yes it's definitely not nice to call memset() in such a tight loop, but
>> the program is just for demonstration purposes. As mentioned at least one
>> gstreamer 1.6 audio decoder plugins will call memset() consecutively fast
>> enough to cause issues with the lcdc dma. And thus screen flicker.
>>
>>
>> So, &variable <- beginning of an array, equivalent to variable[0], but
>>> what is &variable[0] ? A multi dimensional array ? that's not what was
>>> defined . . . to be 100% honest I'm not sure what it does, but the first
>>> thing that comes to mind is "undefined behavior".
>>>
>> I won't go into details, but "&variable" is not the same as "variable[0]".
>> (You might be able construct some special/silly case tho where the content
>> of variable[0] is equivalent to &variable).
>>
>> And "&variable[0]" is equivalent to "variable". The latter might have
>> been more readable in the context of the code, but both version are valid
>> C. Basically you are getting the address of the first element of the memory
>> block, which is the starting address of the memory block itself, which is
>> what memset expects.
>>
>>
>>> On Tue, Mar 8, 2016 at 5:39 PM, <[email protected]> wrote:
>>>
>>>> I'm surprised that code would compile at all without a compiler error.
>>>>> As &variable[0] probably is not what you think it is.
>>>>>
>>>> I see no issue here. Can you elaborate?
>>>>
>>>>
>>>>> Also, for the record, infinitely allocating an arbitrary amount of
>>>>> dynamic memory, in a loop, without any kind of a pause is going to eat up
>>>>> an incredible amount of CPU cycles. As in that code will very likely use
>>>>> as
>>>>> close to 100% CPU as the system will allow it. Which again, is no wonder
>>>>> you're "flickering" . . .
>>>>>
>>>> The code is not allocating anything in a loop.
>>>>
>>>>
>>>>> You lucky your program does not randomly crash for using malloc() on
>>>>> the same dynamic memory over, and over, without using free(), or instead
>>>>> using realloc() . . .
>>>>>
>>>> Because it's not calling malloc() over and over...
>>>>
>>>>
>>>> The issue here is that if you run memset() in a tight loop (which at
>>>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up
>>>> the
>>>> data bus enough for the DMA to fail.
>>>>
>>>>
>>>>
>>>>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> we had very similar issue, which we encountered when updating to
>>>>>> gstreamer 1.6. Using git bisect we were able to find a root cause and
>>>>>> prepare simple test program, which reliably reproduces the issue:
>>>>>>
>>>>>> #include <string.h>
>>>>>> #include <stdint.h>
>>>>>> #include <stdlib.h>
>>>>>>
>>>>>> int main(int argc, char **argv)
>>>>>> {
>>>>>> int size;
>>>>>> uint8_t *memblock;
>>>>>>
>>>>>> if (argc < 2)
>>>>>> return -1;
>>>>>>
>>>>>> size = atoi(argv[1]);
>>>>>>
>>>>>> memblock = malloc(size);
>>>>>>
>>>>>> while (1)
>>>>>> {
>>>>>> memset(&memblock[0], 0, size);
>>>>>> }
>>>>>>
>>>>>> free(memblock);
>>>>>>
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> starting this program will cause crazy flickering, ...
>>>>>>
>>>>>> We were able to reproduce the issue with
>>>>>>
>>>>>> 1) debian originally provided on beaglebone using memtest utility for
>>>>>> carlos. Kernel version was:
>>>>>>
>>>>>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc
>>>>>> version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015
>>>>>>
>>>>>> 2) latest version of debian from beaglebone website Kernel version
>>>>>> was:
>>>>>>
>>>>>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc
>>>>>> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58
>>>>>> UTC
>>>>>> 2016
>>>>>>
>>>>>> so it seems to be existing for ages.
>>>>>>
>>>>>> Did you in the mean time managed to find a solution for your problem?
>>>>>>
>>>>>> Thanks,
>>>>>> Radek
>>>>>>
>>>>>> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi there,
>>>>>>>
>>>>>>>
>>>>>>> i was able to get my 10.1 custom Display to work with the RGB Pins
>>>>>>> on the beaglebone black.
>>>>>>>
>>>>>>> I am using the latest Debian Jessie image from beagleboard.org and
>>>>>>> the X11 Desktop has the right colors and the right size.
>>>>>>>
>>>>>>> So i assume that the Timings from my display are correct.
>>>>>>>
>>>>>>>
>>>>>>> panel {
>>>>>>>
>>>>>>> status = "okay";
>>>>>>>
>>>>>>> compatible = "ti,tilcdc,panel";
>>>>>>>
>>>>>>> pinctrl-names = "default";
>>>>>>>
>>>>>>> pinctrl-0 = <&bb_lcd_lcd_pins>;
>>>>>>>
>>>>>>> panel-info {
>>>>>>>
>>>>>>> ac-bias = <255>;
>>>>>>>
>>>>>>> ac-bias-intrpt = <0>;
>>>>>>>
>>>>>>> dma-burst-sz = <16>;
>>>>>>>
>>>>>>> bpp = <32>;
>>>>>>>
>>>>>>> fdd = <0x80>;
>>>>>>>
>>>>>>> tft-alt-mode = <0>;
>>>>>>>
>>>>>>> stn-565-mode = <0>;
>>>>>>>
>>>>>>> mono-8bit-mode = <0>;
>>>>>>>
>>>>>>> sync-edge = <0>;
>>>>>>>
>>>>>>> sync-ctrl = <1>;
>>>>>>>
>>>>>>> raster-order = <0>;
>>>>>>>
>>>>>>> fifo-th = <0>;
>>>>>>>
>>>>>>> };
>>>>>>>
>>>>>>> display-timings {
>>>>>>>
>>>>>>> native-mode = <&timing0>;
>>>>>>>
>>>>>>> timing0: 1280x800 {
>>>>>>>
>>>>>>> clock-frequency =
>>>>>>> <70000000>;
>>>>>>>
>>>>>>> hactive = <1280>;
>>>>>>>
>>>>>>> vactive = <800>;
>>>>>>>
>>>>>>> hfront-porch = <80>;
>>>>>>>
>>>>>>> hback-porch = <60>;
>>>>>>>
>>>>>>> hsync-len = <20>;
>>>>>>>
>>>>>>> vback-porch = <12>;
>>>>>>>
>>>>>>> vfront-porch = <8>;
>>>>>>>
>>>>>>> vsync-len = <3>;
>>>>>>>
>>>>>>> hsync-active = <0>;
>>>>>>>
>>>>>>> vsync-active = <0>;
>>>>>>>
>>>>>>> };
>>>>>>>
>>>>>>> };
>>>>>>>
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>>> But when i play a video or when i have many frames on the display i
>>>>>>> get some screen flickers.
>>>>>>>
>>>>>>>
>>>>>>> On the log via UART i see the following:
>>>>>>>
>>>>>>>
>>>>>>> 1- When booting up: of_graph_get_next_endpoint(): no port node found
>>>>>>> in /ocp/lcdc@4830e000
>>>>>>>
>>>>>>> 2- When video or many frames are displayed:
>>>>>>>
>>>>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
>>>>>>> underflow
>>>>>>>
>>>>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
>>>>>>>
>>>>>>>
>>>>>>> Any idea?
>>>>>>>
>>>>>>>
>>>>>>> Is the DDR flash rate to slow? Or the DMA buffer not big enougth?
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
