|
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! Thanks for any help! Shannon |
|
|
tiny libc?
Started by ●August 20, 2004
Reply by ●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! 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 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 ●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 ●August 21, 20042004-08-21
|
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! 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 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 ●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 |
