Free eGUI up-to-date CW project

[kubiznak_petr]

Hi,

Is there any up-to-date CodeWarrior demo project for the free eGUI? I'm unable to build any of what I found (with MQX 4.1.1 and latest revision of free eGUI from github).

The one project which is most promissing, gives the following error (on multiple places):

C:/Freescale/D4D_free/repo/D4D/common_files/d4d_string.c: In function 'D4D_LCD_PrintStr':

C:/Freescale/D4D_free/repo/D4D/common_files/d4d_string.c:643:3: error: wide character array initialized from incompatible wide string

mingw32-make: *** [D4D/common_files/d4d_string.o] Error 1

In this case, the problem is the following line:

const D4D_TCHAR pLongTextEnd[] = D4D_DEFSTR("...");

I found a solution which allows me to build it successfully: Using the -fshort-wchar compiler flag. But I get tons of linker warnings of the following type:

e:/program files/cw mcu v10.6/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: warning: C:/Freescale/Freescale_MQX4/lib/twrk70f120m.cw10gcc/debug/bsp/bsp.a(mqx_main.o) uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t values across objects may fail

I know it's "just" a warning, but I believe this type of warning might be really critical, or am I wrong?

I can build MQX with the same flag to eliminate these warnings, but the application links with some standard libraries, e.g. Cross_Tools/arm-none-eabi-gcc-4_7_3/arm-none-eabi/lib/armv7e-m/softfp\libsupc++.a(eh_globals.o) So the warnings remain here.

It might be possible to rebuild these libraries as well, but this is not the way I want to go. So I would really like to find a demo CW project for the latest eGUI, which builds with MQX and standard libraries without changing the configuration. Can someone please provide?

[LuisCasado]

Hello,

Try this one

Best Regards,

Luis

[kubiznak_petr]

Hi Luis,

Thank you for your response. Unfortunately, the new project does not solve the problem. The difference is not in project settings, but in D4D configuration. Your (referential) d4d_user_config_app.h does not enable unicode:

//#define D4D_UNICODE                        // Enables Unicode support

For this reason, D4D_TCHAR is defined as D4D_CHAR in your project, while D4D_WCHAR in mine. And for this reason, the problematic line works in your project but not in mine:

D4D_TCHAR str_touch[10] = D4D_DEFSTR("X1:00000");

Obviously, wchar_t is 32bit with gcc, and this line cannot be compiled then. Is there any other quick fix different then giving up Unicode?

[LuisCasado]

Hi  Petrs,

I see. What I would do is to port the IAR project from eGUI github (latest) to CW10.6. There are too many changes in the sources, the true Unicode support was included in the 3.0 release. You can use this project as reference, changing all the sources and paths in the project to build the eGUI 3.0 sources.

Regards,

Luis

[kubiznak_petr]

This cannot be fixed by "copying" settings from IAR project to CW project, because of different default configuration of standard libraries used by the IDE's. The only clean solution I can see is to find a compiler option which would fix it. I tried -D_EWL_WIDE_CHAR=1, with no success (generates much more new errors). I'm not familiar with CW, so it is hard for me to find the proper option, if it exists.

[Gargy]

Try to, define in d4d_usr_config.h  own type D4D_WCHAR:

You have to pull the latest master branch from gitHUB (I correct the definition - Commit: 1651c05c178c3a7ee2c83daf12101a77cbb21118 [1651c05]) and try define your type for WCHAR. like:

#define D4D_WCHAR_TYPE  unsigned long

Let me know if this works.

Petr

[kubiznak_petr]

Hi Petr,

Thank you, but this commit does not really change anything. I already tried that yesterday, just redefining D4D_WCHAR directly:

#define D4D_WCHAR  unsigned long

I tried even all other possible (while incorrect) types: signed long, signed short, signed char, unsigned char... Nothing helps, the result is the same. I also tried to use wchar_t, but it does not seem to be defined in <wchar.h>.

I worry this issue will require for-loop to be fixed properly. Or all the standard libraries would have to be rebuilt with -fshort_wchar, but this is not a well-portable solution (even though it is cleaner). I will report this as bug on github, and turn off Unicode in my project, as I can live without it. Please let me know if you come up with some solution.