RFC: FreeRTOS core without libc

apr-cn-eng wrote on Thursday, July 31, 2008:

While throwing out the stack hog sprintf from my application, I took a closer look at the libc function usage inside of the FreeRTOS core (FreeRTOS/source/*). While the various demo applications rely on sprintf, etc. the core itself is pretty clean here:
  memcpy()    queue.c
  memset()    tasks.c
  sprintf()   tasks.c
  strcat()    tasks.c
  strncpy()   tasks.c
Most of these can be replaced easily, esp. the string functions.

A short comparison with a minimal main and a pretty complete FreeRTOS revealed below numbers.
Compilation was done with -O2, using FreeRTOS 5.0.0, GCC/ARM7_LPC23xx, gcc 4.2.2, newlib 1.16.

official source incl. sprintf in tasks.c
   text    data     bss     dec     hex
  43000    2092   25156   70248   11268

replaced sprintf with siprintf in tasks.c
   text    data     bss     dec     hex
  26232    2076   25144   53452    d0cc

removed sprintf from tasks.c
   text    data     bss     dec     hex
  10420       8   24912   35340    8a0c

The remaining libc functions are not that huge, summing up in 1004 byte of code, no data/bss usage.

As many applications only use the core itself and omit libc usage completely or at least the printf family because of its stack usage, I’d suggest to remove most or all of the libc references from the FreeRTOS core.

This can be done by either by replacing the concerned code with equivalent routines or by using precompiler defines mapping them either to the libc functions or to local helper code.
I’d opt for a combination of both:
  - replace all libc references with preprocessor defines (SPRINTF, etc.)
  - map the commonly used functions like memcpy to libc
  - map sprintf, etc. to helper functions or at least siprintf

  - Where to put the defines and the helper code
  - How to document this, esp. as siprintf might not be available everywhere
    and behaviour might change unexpected (fence libraries replacing memcpy, etc.)
  - Chances for inclusion in the official FreeRTOS codebase

I’d volunteer to implement a clean solution based on the discussion results here, given it will be included in the official FreeRTOS code.

Best regards,
  A. Pretzsch

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch                 Tel. xxxx/xxxxx-xxx
Marlene-Dietrich-Strasse 5                       Fax: xxxx/xxxxx-xxx
89231 Neu-Ulm                                    email: xxxx@xxxx

davedoors wrote on Thursday, July 31, 2008:

Quite a few of the demos include printf-stdarg.c to provide a lean sprintf formatter. The GCC version is generally hopeless for low RAM apps.

memcpy() queue.c
memset() tasks.c
sprintf() tasks.c
strcat() tasks.c
strncpy() tasks.c

These should be tiny. The problem comes when you need to have the library code check for different buffer alignment, but even then they should be small. You can use the -ffunction-sections and -fdata-sections compiler options and the --gc-sections linker option to stop all the library junk being included in the build.

Using the existing code but without the trace feature included I would expect the build to be closer to 5K.

How would you go about taking out the library functions in a portable way? I agree it would be beneficial.