Page 2 of 2

Re: Benchmark SSD1289

Posted: Mon Jun 03, 2013 10:34 pm
by Eddie
ok, thank you. In ADS7843 driver must be file "ginput_lld_mouse.c" also commited ;)

I tried various demo from GFX and I have a problem. In the demo, where the option "GDISP_NEED_MULTITHREAD" must be enabled, program working only with optimization -O2, when I switch to -O0, program stop in unhadled exception in first mutex lock. Increase stack size not solve the problem. This happening in master branch, demo in branch 1.6 working with -O0 without problem :(

Re: Benchmark SSD1289

Posted: Tue Jun 04, 2013 5:35 am
by Tectu
The new ADS7843 board file inclusion has been added. This madness will disappear in the near future anway.
The -O0 issue is something I already experienced myself. However, I currently didn't have time nor the knowledge to quickly solve this issue. If you want to digg into it, you're welcome :)


~ Tectu

Re: Benchmark SSD1289

Posted: Thu Jun 13, 2013 3:41 am
by inmarket
Yes optimisation problems are common. For my implementations -O2 never works (causes ChibiOS to crash) so I need to use -O0.

Note that since the C source code hasn't changed, this problem with -O? is actually highlighting bugs in the gcc optimiser. The compiler is in some cases generating incorrect machine code. Typically this happens with higher optimisation levels (-O2 is more likely to be problematic that -O0).
If you are finding lower optimization levels are causing problems the issue might be that you are running borderline for stack space and the lower optimisation level is increasing your stack usage.

Re: Benchmark SSD1289

Posted: Thu Jun 13, 2013 4:01 pm
by Eddie
I have exactly the opposite problem, project compiled with -O0 never works, always ends in unhandled exception.
Can you post please sample working project, which uses "GDISP_NEED_MULTITHREAD TRUE" and options -O0 ?

Re: Benchmark SSD1289

Posted: Fri Jun 14, 2013 2:41 am
by inmarket
Just add

Code: Select all

#define GDISP_NEED_MULTITHREAD TRUE

to your gfxconf.h file.
If, as I suspect. your problem with -O0 is due to increased stack usage, this needs to be fixed in the ChibiOS linker script. How much you increase it by will depend on your application requirements. Refer to the ChibiOS forum on increasing the thread stack space for your platform.

Re: Benchmark SSD1289

Posted: Fri Jun 14, 2013 7:22 am
by Tectu
inmarket: What compiler are you using? I have the exact opposite problem of yours, the same as Eddie described. Stuff never works with -O0 here but always finde with -O2.


~ Tectu

Re: Benchmark SSD1289

Posted: Sat Jun 15, 2013 12:59 am
by inmarket
For Win32: I am using mingw32
For ARM: yagarto

I have the same issue with both: -O2 fails to produce good code.

As an example in gtimer.c

Code: Select all

/* Don't rework this macro to use a ternary operator - the gcc compiler stuffs it up */
#define TimeIsWithin(x, start, end)   ((end >= start && x >= start && x <= end) || (end < start && (x >= start || x <= end)))


This function is similar to a ChibiOS function (of a similar name), and the compiler stuffs that up too with -O2. It also re-orders statements in the scheduler and thread locking functions of ChibiOS affecting the locking of structures which I think is the primary cause for occasional crashes with -O2.