26

I am looking for a small libc for embedded use with freertos on a ARM7 microcontroller. I have looked at newlib, but it is a bit too complex for my needs. Newlib calls malloc() in a number of functions (e.g. printf()), which is not good for small embedded realtime systems.

Does anyone know of a small, portable, open source libc implementation that will fit my application?

GT.
  • 901
  • 1
  • 6
  • 10

8 Answers8

12

PDCLib might fit your needs. It's still incomplete [broken link], though, and probably in need of a lot more real-world testing. Its author goes by DevSolar here on SO.

update 2012-11-01: As of 2012-08-14, development has been taken over by Owen Shepherd, complete with a new homepage and bitbucket repository [broken link, use this one].

update 2015-10-31: The dedicated website seems to be dead, but the code can still be found on bitbucket. The last commit to that repository happened 2014-11-24.

update 2016-07-12: The website is back up, and DevSolar started committing again on 2016-03-01.

Community
  • 1
  • 1
Christoph
  • 164,997
  • 36
  • 182
  • 240
  • The page seems to point to http://pdclib.e43.eu/ for current development. It's full of dead links and doesn't seem to say anything about possible OS/HW requirements/support. – XTL Nov 01 '12 at 07:39
  • @XTL: there exist [platform overlays](http://hg.pdclib.e43.eu/pdclib/src/default/platform) for posix and win32, and one of the goals of the project was to be easily portable (see the post mortem written by the original author: he developed it as a service to the hobby OS community); no idea how this works out in practice... – Christoph Nov 01 '12 at 13:30
10

I use newlib on my Cortex_M3 with 32kB RAM, and to eliminate the malloc() you can use siprintf() or sniprintf().

Pro: No more calls to malloc().

Con: It does not suport formatting float and double, and is not really portable this way.

Turbo J
  • 7,563
  • 1
  • 23
  • 43
7

If you use newlib and do not implement the sbrk syscall, then any function you use that requires malloc will generate a linker error, which will prevent you from inadvertently using a call that requires dynamic memory . So I would suggest that you do that, and then simply avoid those functions that cause the linker error. You can modify or override any library functions you do not wish to use.

Clifford
  • 88,407
  • 13
  • 85
  • 165
3

printf() is not good for small embedded realtime systems!

Actually it is worse than malloc in many ways. Variable argument lists, very complex formatting, float number support when you don't need it etc etc. printf() comes with an enormous overhead, and the compiler will not be able to reduce it, as every parameter passed to it is evaluated in runtime.

printf() is perhaps ok for hobbyists and beginners still learning C. But if you are a professional programmer, you really ought to write your own serial monitor / LCD routines. You will dramatically improve the program performance and flash consumption.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • 1
    Though technically not an answer, I liked it. – Prof. Falken Feb 07 '11 at 14:03
  • It *is* an answer. For a small embedded realtime system, you shouldn't be using libraries stdio and stdlib in the first place! MISRA-C bans stdio entirely, for example. – Lundin Feb 07 '11 at 14:18
  • It depends ... I would never call printf() from a real time context, but I don't see any big problems using printf() in non time critial tasks. Calling malloc() should be avoided as much as possible because task creation needs malloc() for the per-task stack frame, and heap fragmentation can quickly lead to OOM situations. It is common to configure freertos with malloc(), but without a functional free() because frequent memory allocation/deallocations on systems with very little memory is considered too "risky". – GT. Feb 07 '11 at 14:31
  • @Lundin: Which MISRA-C compliant library do you recommend? – GT. Feb 07 '11 at 14:43
  • Pardon my bluntness, but the only reasons I can come up with for using printf() is either laziness or lack of knowledge. Why would you use a function needing x kb of flash and y*1000 instructions for something with equal functionality with <100 bytes and <30 instructions? – Lundin Feb 07 '11 at 14:43
  • As for malloc(), I agree completely with everything stated. Apart from the issues with fragmentation and memory leaks, you would also need to allocate a heap in RAM (likely several kb), and in these kind of systems you rarely have enough read/write data to justify it. – Lundin Feb 07 '11 at 14:45
  • @GT I always write my own libraries. But then I don't have much of an option as I only work with safety-critical systems. If you look for MISRA compliance, it is also nice to have written the libraries yourself, as it will be far easier to perform static analysis on your own code, than on some 3rd party lib. – Lundin Feb 07 '11 at 14:47
  • 1
    @Lundin: If printf() will solve the problem at hand, I see no problem using it. To follow your logic, you should not write code in c since assembly would require less flash and execute faster. Heck, why are you even using a microcontroller, a pure ASIC would be even more efficient, and require even less flash ;-) – GT. Feb 07 '11 at 15:23
  • @GT And to follow your logic, you should ship a PC together with every product. – Lundin Feb 07 '11 at 15:58
  • @Lundin: LOL, I guess you are right :-) And I understand your argumentation regarding static analysis. Thanks! – GT. Feb 07 '11 at 17:24
  • 17
    There is nothing wrong with using `printf` in embedded systems. There's something wrong with `printf` implementations that call `malloc` and do all sorts of useless things. A simple `printf` implementation without floating point (or that ignores exactness issues when printing floating point) and without POSIX i18n `%n$` argument specifiers, can be implemented in about 2k of code, and allows the calling application to be much smaller and simpler than if it had to duplicate `printf`-like functionality all over the place. – R.. GitHub STOP HELPING ICE Feb 07 '11 at 19:00
  • Generally, I have seen two types of embedded systems - those with memory measured in kilobytes where one has to be careful not to drag in un-needed capabilities or even let a compiler initialize things in inefficient ways, and ones where you've got tens of megabytes of ram anyway, and retaining the ability to do rich output (at least outside the critical path), even a have an optional login shell, etc is reasonable and convenient. – Chris Stratton Feb 07 '11 at 20:32
  • 1
    "There is nothing wrong with printf..." /--" "...can be implemented in about 2k of code". You obviously haven't worked with small microcontroller applications. 2k is huge. And if you can't even write a simple RS-232 serial monitor by yourself to replace printf(), you shouldn't be programming embedded systems in the first place. – Lundin Feb 07 '11 at 21:00
  • 4
    @Lundin: As Chris said, there's a big range of embedded systems, and often conditions like *realtime* (bounded-time operations) and *failure-case-free* are more important than extremely small memory size. I'd be a lot happier with an embedded device that uses 1 MB of memory but always works because I know where allocations take place than a device that "normally" uses 128 kB and has 256 kB of physical memory, but no strict bounds on usage and fails to do its job when an allocation fails. – R.. GitHub STOP HELPING ICE Feb 10 '11 at 11:38
  • 1
    @R You want realtime and safety and therefore use stdio.h? You *are* joking, right? – Lundin Feb 10 '11 at 14:32
  • They're not quite mutually exclusive, though. – XTL Nov 01 '12 at 07:43
  • 1
    "2K is huge" depends. I wrote two RTOS's that were about 2K. The amount of functionality I implemented in that 2K made for some awesome apps (one was robotics). If printf frees me up from the chore of reinventing the wheel, guess what? I'm using it. Time is money, tick, tock, tock, tock. And, yes, I've worked with SMALL systems that were all in assembly. – Lloyd Sargent May 03 '13 at 21:17
  • By the way, if you omit wide character support or define `wchar_t` as `char` so that the `l` modifier can be ignored, and omit floating point, and don't tweak anything for performance, I bet you can get `printf` a lot smaller than 2k. Maybe under 0.5k even. – R.. GitHub STOP HELPING ICE Jun 23 '13 at 02:33
3

I had similar needs and found that klibc fit it quite well. The only downside (for commercial use) is that the distribution includes a few GPL-licensed files, even though most of it is BSD-licensed. I have hacked a minimal version of it here.

This is even more limited than PDCLib, and suitable if you just need a few basic functions such as printf and strtok. Compiles to just 4kB with all functions included.

jpa
  • 10,351
  • 1
  • 28
  • 45
2

You might want to look into the Embedded Artistry libc, which promises to be minimal and well-tested. It includes a malloc-free printf(). Disclaimer: I have not used it, but it appears well-structured and actively developed.

SethML
  • 701
  • 5
  • 2
1

You can check out the LGPL µClibc, which is supposed to be close to glibc but much more suited to embedded systems.

It also has a page referencing other open source C libraries, including newlib and eCos, which may be more suited for non-Linux environments.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
-2

Look into uClibc and EGLIBC, perhaps.

unwind
  • 391,730
  • 64
  • 469
  • 606