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

Questions:
- 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. 0731/98588-800
Marlene-Dietrich-Strasse 5 Fax: 0731/98588-801
89231 Neu-Ulm email: apr@cn-eng.de

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.