Latest github changes

[crteensy]

Hi,

I checked out ugfx yesterday and first tried the new "single file" mode of compilation, which worked great. Thanks for that! However, some problems:

• I'm compiling for an STM32F030F4P6, which has only 16kB flash. With ugfx 2.3, it's almost full. With the latest github (checked out 20150615) I can't squeeze it below some 70 kB (!). It's well possible that there's something wrong with my compiler and linker setup, though, but it happens when compiling ugfx as a single file and in the "old" way with many individual source files.
  
• When including ugfx in a C++ project, it redefines types such as uint16_t. I had to comment that out. With 2.3, I could solve that by simply rearranging headers, but not any more. I found a suspicious commit here: https://bitbucket.org/Tectu/ugfx/diff/src/gos/gos_raw32.h?diff2=81850ade15e7&at=master.

Regards

Christoph

[inmarket]

I am not sure why your code size has suddenly grown so much but here are a few things to check...

1. The options in your gfxconf file make a HUGE difference to the end code size. Turn off options you don't need.

2. Storing images using GFILE ROMFS will take up a lot of flash.

3. The compiler optimiser can make a big difference but the gcc optimiser is particularly buggy and stops things from working so increase your optimisation one level at a time until it doesn't work.

4. Make sure the link optimiser is turned on in your makefile. It also can make a big difference.

With regard to type redefinition, we are playing a losing battle. The commit that you mention was an attempt to do the standard definitions in a more portable way using one of the c standards specified header files. It should have reduced problems for you. Unfortunately the world is not that simple and compilers are seldom really compliant with the standards. It is one of those sorts of problems you have struck.

GIven this I have been tempted to go through and create our own type names for these however that is a ton of work and introduces compatibility problems for existing users.

I am therefore open to any way you can think to make it more compatible. In the mean time try with those lines reverted to the old method to ensure that that change was the cause of the problem.

By the way, you might want to try the alternative schedular branch. It contains updates for the threading support for raw32 and arduino and should prevent hard faults that use to occur. Changes:

GOS_RAW_HEAP_SIZE is now called GFX_OS_HEAP_SIZE.

Try also defining GFX_CPU = GFX_CPU_CORTEX_M0.

Hopefully that last define will use a cpu specific schedular which is much smaller and faster than the generic one.

Let me know how it goes for you if you have time to play with it as I am hoping to roll it into the master branch in a couple of weeks.