Reply by Pablo Bleyer Kocik●August 23, 20042004-08-23
At 18:43 21-08-2004, you wrote:
>Just be aware the uClibc is GNU licensed and if
statically linked
>with your code, can have impact upon your licensing. This might not
>be a problem with hobby or internal projects but could be with
>commercial ones.
It is LGPL licensed, which means you don't have to release your *source*
code but provide an uClibc re-linkable object file of your statically
linked code.
Regards.
--
PabloBleyerKocik/"Freedom of religion afforded only to Christians
pbleyer2004 / in US, a secular state with no official religion."
@embedded.cl/ -- This place sucks 28.6.02, Gene Kan
Just be aware the uClibc is GNU licensed and if statically linked
with your code, can have impact upon your licensing. This might not
be a problem with hobby or internal projects but could be with
commercial ones.
Regards
-Bill Knight
R O SOftWare
On Sat, 21 Aug 2004 10:42:09 -0400, Pablo Bleyer Kocik wrote:
At 21:43 20-08-2004, you wrote: >Hello all,
>I'm starting to bump up against the 128KB
flash limit in my LPC2106 and
>am looking for ways to make things smaller. Switching to the gnuarm.org
>gcc 3.4.1 and thumb mode (along with adding -Os to my CFLAGS) made
>things more then small enough but the code didn't work. Found a
pretty
>explicit codegen bug in some of the FreeRTOS code (definitely NOT a bug
>in FreeRTOS) - yes, I will isolate this some more and report it. If I
>turn off -Os then the code get's big enough (around 20KB larger!)
and
>so I don't fit.
Yes, there is a bug in GCC 3.4.1 regarding THUMB mode. This has been
fixed in CVS. I still have been unable to allocate time to release an
interim version with the proper bug fixes. Most probably it will have to
wait to 3.4.2 ;^/
>I've found many very small libc's, but
they are typically an explicit
>port to a processor (AVR, MSP430, etc). That could certainly be a
>starting point, but I'd rather avoid that much work if I don't
need to
>do it!
Regards.
--
PabloBleyerKocik /"It is nothing short of a miracle that modern methods
pbleyer / of instruction have not yet entirely strangled the
@embedded.cl / holy curiousity of inquiry." -- Albert Einstein
Yahoo! Groups Links
Reply by Shannon Holland●August 21, 20042004-08-21
On Saturday, August 21, 2004, at 07:42 AM, Pablo Bleyer Kocik wrote:
> Yes, there is a bug in GCC 3.4.1 regarding THUMB
mode. This has been
> fixed in CVS. I still have been unable to allocate time to release an
> interim version with the proper bug fixes. Most probably it will have
> to
> wait to 3.4.2 ;^/
Cool - glad to know it's fixed! If I get the latest gcc sources will it
be something I can easily build and test out or will that likely get me
lots of 3.5 changes as well?
>
>> I've found many very small libc's, but they are typically an
explicit
>> port to a processor (AVR, MSP430, etc). That could certainly be a
>> starting point, but I'd rather avoid that much work if I
don't need to
>> do it!
>
> Perhaps uClibc (http://www.uclibc.org/) may fit your needs. It is at
> least more easier to trim than newlib. There is also uC-libc, take a
> look
> at http://www.ucdot.org/article.pl?sid/08/21/1124218
>
I've been using uClibc at work for a client who is building an embedded
linux system (just built it as part of buildroot, which is an awesome
package!). That was my first plan of attack, although when poking
around the web I found various references saying a non-linux build
wasn't supported - not sure how true that really is. I had started
trying to build a uclibc toolchain but keep hitting build problems -
for some reason gcc really hates to compile for me! As you say, uClibc
is very configurable so it's probably worth spending time on.
As an interim hack, I just tried linking without libc to see how many
errors I got - turns out it's very little. So I think I will just plug
in my own functions for now, then once 3.4.2 is out I can go back to
getting a happy uClibc.
Thanks!
Shannon
Reply by Pablo Bleyer Kocik●August 21, 20042004-08-21
At 21:43 20-08-2004, you wrote: >Hello all,
>
>I'm starting to bump up against the 128KB flash limit in my LPC2106
and
>am looking for ways to make things smaller. Switching to the gnuarm.org
>gcc 3.4.1 and thumb mode (along with adding -Os to my CFLAGS) made
>things more then small enough but the code didn't work. Found a
pretty
>explicit codegen bug in some of the FreeRTOS code (definitely NOT a bug
>in FreeRTOS) - yes, I will isolate this some more and report it. If I
>turn off -Os then the code get's big enough (around 20KB larger!)
and
>so I don't fit.
Yes, there is a bug in GCC 3.4.1 regarding THUMB mode. This has been
fixed in CVS. I still have been unable to allocate time to release an
interim version with the proper bug fixes. Most probably it will have to
wait to 3.4.2 ;^/
>I've found many very small libc's, but
they are typically an explicit
>port to a processor (AVR, MSP430, etc). That could certainly be a
>starting point, but I'd rather avoid that much work if I don't
need to
>do it!
Regards.
--
PabloBleyerKocik /"It is nothing short of a miracle that modern methods
pbleyer / of instruction have not yet entirely strangled the
@embedded.cl / holy curiousity of inquiry." -- Albert Einstein
Reply by Shannon Holland●August 20, 20042004-08-20
Hello all,
I'm starting to bump up against the 128KB flash limit in my LPC2106 and
am looking for ways to make things smaller. Switching to the gnuarm.org
gcc 3.4.1 and thumb mode (along with adding -Os to my CFLAGS) made
things more then small enough but the code didn't work. Found a pretty
explicit codegen bug in some of the FreeRTOS code (definitely NOT a bug
in FreeRTOS) - yes, I will isolate this some more and report it. If I
turn off -Os then the code get's big enough (around 20KB larger!) and
so I don't fit.
Needing to move forward, I went back to gcc 3.3.3 but there with thumb
mode on I was still way over 128KB (3.4.1's code was much smaller).
I don't need a whole lot from libc, but am including some code that
does expect reasonable support, at least strings and sprintf. newlib
looks to be taking around 40-50KB so it's a prime target for reduction.
I'm rebuilding it now with some options turned on to reduce size, but I
doubt it will be enough. The reality is that I really don't need fileio
support, etc for my app.
So, a couple of questions:
1. Has anyone looked at really trimming down newlib?
2. Are there any other c libraries out there that are smaller and
arm/gcc compatible?
I've found many very small libc's, but they are typically an explicit
port to a processor (AVR, MSP430, etc). That could certainly be a
starting point, but I'd rather avoid that much work if I don't need to
do it!
