LPC214x BSP?

[Joel Sherrill]

ray wrote:
> Hi Dave Madden
> I remember that Joel said the latest RTEMS is tuned for code footprint in his mail a few days before. So you may want to try his latest change in.
> In order to minimize the SRAM usage, you can change the linkcmds file (I think you have already made some change to this file to make things run). The lpc2210 can use external SRAM, so I do not take effort to limit the RAM usage. I also enabled the Ethernet support in the BSP. Both will consume some RAM.  I think you can tune the linkcmds to save some memory.
> I think RTEMS can run in 32K RAM space, although I never have chance to try that.
>
>   
My efforts to reduce size have been focused on code size with very 
little, if any,
impact on .data or .bss.

The .data and .bss sizes are because all global variable declarations in 
RTEMS are
done in the API initialization routine.  So you get all the POSIX data 
or all the Classic
API data as a set.

Once I am happy with the code (.text) size, making each manager data get 
instantiated
in separate files is on my list.  This will help some.

The next part of .data/.bss size is harder and more controversial since 
it requires conditional
compilation and major variances in RTEMS features based upon how it is 
built by the user.
For example, RTEMS always supports 256 priority levels.  If you reduced 
this to 16, then
you save about 2900 bytes of BSS.  But this MUST be conditionally 
compiled and its impact
on test and application code must be evaluated seriously before we 
consider implementing it.

Some hints to reduce size as far as easily possible. 

  + Use 4.7.1 rather than 4.7.0
  + Be careful in your BSP's Makefile.am around startup code.  Look
     at sparc/erc32.  You don't want the miscellaneous code to become a
     lump that pulls in other stuff.
  + Make sure your BSPs debug IO support doesn't result in the entire
     console driver  coming in.    If it does, then termios comes in also.
  + configure with itron and posix disabled
  + add -DNDEBUG to your build cflags.

I can get down to the low 50K's on .text on sparc/erc32 with the CVS head
and the above tricks.  There is a bit more code to trim but it is 
getting harder
to decouple pieces as there is less and less left.  This doesn't help 
you squeeze
into your 32K though. But careful linker script magic could move a lot to an
external RAM module if you have one.

In general terms 32K is not a lot of memory.  newlib's printf alone is 
quite hefty
when compared to 32K.  Try this out to see how much code from libc.a printf
requires.

bash-3.1$ arm-rtems4.8-ld -u printf 
/opt/rtems-4.8/arm-rtems4.8/lib/libc.a -r -o printf.rel
bash-3.1$ arm-rtems4.8-size printf.rel
   text    data     bss     dec     hex filename
  25320    1044      12   26376    6708 printf.rel

Do an "nm" on that .rel and notice what it still has listed as 
undefined.  Lots of soft-float
support, malloc family calls, isatty, read, and close. 

That 25K above applies for any arm-elf or arm-rtems gcc/newlib toolset. 

--joel

>
> ------------------
> Thanks & Best Regards!
> ray
> 2007-04-23
>
> -------------------------------------------------------------
> From: dave madden
> Date: 2007-04-23 01:11:48
> To:   rtems-users at rtems.org
> CC:   xr at trasin.net
> Sub:  Re: LPC214x BSP?
>
>   
>>>>>> "ray" == xr-at-trasin-dot-net at example.com writes:
>>>>>>             
>
>     ray> Hi I have submitted a BSP for LPC2210(rt22xx) a few months
>     ray> ago. It had not been integrated into RTEMS4.7 yet.  But I
>     ray> think these two processors is pretty same. So it may be
>     ray> better to begin with my BSP.
>
> Hi Ray.
>
> Thanks for sending your BSP.  I was able to convert it over to load &
> start on the 2148, but it dies very soon.  The 2148 only has 32k of
> RAM (plus another 8K for USB), but "Hello World" has a linked data/bss
> size of ~12K, and there's a ~15K allocation pretty early in the
> startup process.  I haven't tracked it down, but I suspect the 2148
> simply doesn't have enough memory to run a non-trivial RTEMS program.
>
> Best regards,
> d.
>
>
>
>