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
Benchmark SSD1289
Re: Benchmark SSD1289
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
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
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.
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.
-
- Posts: 44
- Joined: Sat Mar 16, 2013 5:57 pm
- Location: Czech Republic
- Has thanked: 2 times
- Been thanked: 6 times
Re: Benchmark SSD1289
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 ?
Can you post please sample working project, which uses "GDISP_NEED_MULTITHREAD TRUE" and options -O0 ?
Re: Benchmark SSD1289
Just add
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.
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
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
~ Tectu
Re: Benchmark SSD1289
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
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.
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 17 guests