Benchmark SSD1289

Eddie
Posts: 40
Joined: Sat Mar 16, 2013 5:57 pm
Location: Czech Republic
Been thanked: 6 times

Re: Benchmark SSD1289

Postby Eddie » Mon Jun 03, 2013 10:34 pm

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 :(

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: Benchmark SSD1289

Postby Tectu » Tue Jun 04, 2013 5:35 am

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

inmarket
Posts: 89
Joined: Fri Jul 27, 2012 1:37 pm
Location: Brisbane, Australia

Re: Benchmark SSD1289

Postby inmarket » Thu Jun 13, 2013 3:41 am

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.

Eddie
Posts: 40
Joined: Sat Mar 16, 2013 5:57 pm
Location: Czech Republic
Been thanked: 6 times

Re: Benchmark SSD1289

Postby Eddie » Thu Jun 13, 2013 4:01 pm

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 ?

inmarket
Posts: 89
Joined: Fri Jul 27, 2012 1:37 pm
Location: Brisbane, Australia

Re: Benchmark SSD1289

Postby inmarket » Fri Jun 14, 2013 2:41 am

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.

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: Benchmark SSD1289

Postby Tectu » Fri Jun 14, 2013 7:22 am

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

inmarket
Posts: 89
Joined: Fri Jul 27, 2012 1:37 pm
Location: Brisbane, Australia

Re: Benchmark SSD1289

Postby inmarket » Sat Jun 15, 2013 12:59 am

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.


Return to “LCD Driver and Graphic Framework”

Who is online

Users browsing this forum: No registered users and 0 guests