Lpc2000

--- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:

> Keil gcc uses uclibc, the version you require is:
> 
> int write (int file, char * ptr, int len)
> {
>     return len;
> }

Thank you, Spen. You are right: I've overridden write() and now 
printf outputs to the UART0. But there is an issue and I think it 
might be related to what you said next:

> Be careful of uisng uclibc as a clib, even though it is a better 
lib 
> for smaller devices it comes under lgpl rather than gpl. This is 
only 
> really a problem if you are statically linking with the libs.

Well, the issue is: the .HEX file generated with GCC is enormous! 
Like 56 kb for a prog that only prints a single formatted variable 
to UART0. The exact same code compiled with "Keil ARM Tools" 
generates a .HEX file that is only 10 kb big.

Do you guys think that such a gigantic .HEX file is because of 
this "statically linking" problem of uclibc? If so, what alternative 
lib do you suggest?

Fernando

--- In lpc2000@yahoogroups.com, "tiogate" <gate@t...> wrote:
> 
> --- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
> 
> > Keil gcc uses uclibc, the version you require is:
> > 
> > int write (int file, char * ptr, int len)
> > {
> >     return len;
> > }
> 
> Thank you, Spen. You are right: I've overridden write() and now 
> printf outputs to the UART0. But there is an issue and I think it 
> might be related to what you said next:
> 
> > Be careful of uisng uclibc as a clib, even though it is a better 
> lib 
> > for smaller devices it comes under lgpl rather than gpl. This is 
> only 
> > really a problem if you are statically linking with the libs.
> 
> Well, the issue is: the .HEX file generated with GCC is enormous! 
> Like 56 kb for a prog that only prints a single formatted variable 
> to UART0. The exact same code compiled with "Keil ARM Tools" 
> generates a .HEX file that is only 10 kb big.
> 
> Do you guys think that such a gigantic .HEX file is because of 
> this "statically linking" problem of uclibc? If so, what 
alternative 
> lib do you suggest?
> 
> Fernando

To improve code size especially for smaller arm devices you need to 
pass the linker switch --gc-sections - this will remove redundant 
code.
Compile your source files with -ffunction-sections -fdata-sections 
aswell.

Note: you will need to use the KEEP directive in your linker script, 
eg. KEEP(*(.startup))
It will only need doing on the startup/vectors as the main will be 
called fom there. You will get strange problems if there is no keep 
directive, eg. no code.

The best solution of all is to rebuild the c library with -ffunction-
sections -fdata-sections - this is what I do and the code size is a 
lot smaller.

I use newlib as a c library and when rebuilt with above options 
produces code size as good as uclibc.
Also keil gcc uses gcc 3.31 which is quite outdated now - I use 3.4.3 
built from source - slightly more efficient, especially for thumb.

Hope this helps
Spen