0

I was recently asked about how to use a C library (Cello in this case) in an embedded environment, but I'm not sure how to go about that.

Is it correct to say that if a library can be compiled in the embedded environment, it can be used? Should I care about making the library more lightweight or something like that?

Any suggestions are appreciated.

AbsoluteSpace
  • 710
  • 2
  • 11
  • 21
Nguyen Cong
  • 174
  • 1
  • 13
  • 1
    This particular lib sounds like one that you don't _want_ to have in an embedded environment. Your very first question you need to ask is: why do I need this lib in the first place? – Lundin Jun 20 '19 at 07:33
  • Cello looks like a vanity project rather then something you would want to put in production - the FAQ pretty much says that. I couldn't at first figure out how it worked with the illegal identifier name `$`, but it is a pre-processor macro that GCC allows by extension so is not portable https://stackoverflow.com/questions/369495/what-are-the-valid-characters-for-macro-names. If you want a "better C", there is C++. You general question would attract less opinion comment if you omit Cello from the question. – Clifford Jun 20 '19 at 11:20
  • Whether it needs to be "lightweight" depends entirely on your system. I'd be more concerned about real-time performance and deterministic behaviour, and if Cello truly does garbage collection it probably fails to meet those criteria. – Clifford Jun 20 '19 at 11:22
  • As noted in my answer if you are looking for an "better" C the [espruino](https://www.espruino.com/) runs javascript and is highly useable for hobbyist projects. @Clifford I think Cello should stay in the question as it is an example of a lib that shouldn't be included even though it might be able to be compiled after modification. – Tarick Welling Jun 20 '19 at 14:24
  • @TarickWelling Perhaps (re Cello), but it makes the question rather more specific than the title. A 'normal C library' is just a library - a collection of compiled or assembled object code. In that sense, there is nothing special about an embedded environment. Any library must be built for the target, and there may be target dependencies and constraints. In that sense the question is too broad, since neither 'normal C' nor the 'embedded environment' are defined. – Clifford Jun 20 '19 at 14:34
  • Maybe moving that part of the question to the bottom could improve the question as a practical example? – Tarick Welling Jun 20 '19 at 14:36
  • I just want to have an overview of what should be done to port a C library which can be run on x86-64 to an embedded environment. – Nguyen Cong Jun 21 '19 at 01:36

2 Answers2

2

Not all libraries that can be compiled, can be used in embedded environments. Libraries that use malloc and free (or their C++ counterparts) are dangerous and therefore should be handled with care. These libraries can result in undeterministic behaviour because of memory allocations failing.

It is possible that the standard C STD could be wholly compiled for embedded devices but that doesn't mean that you'll have much use for printf or scanf. So a better question before you ask if you can compile it is should you use it. Cello seems like a fun experiment but isn't a stable platform to develop something real on. It can be done though and an example of that is the Espruino.

Most of the time it is a bad idea to rewrite a library to be 'lightweight' or more importantly in an embedded environment: statically allocated. You are probably not as smart as those people or won't put in the time needed to create a complete functional embedded fork which is as stable as the original or even better. Don't be dissuaded for a fun little side project but don't depend on it for a real project.

Another problem could be that the library is too big for your microcontroller. The Atmega32a only has 32KB of programmable flash. To take a C++ example of the top of my head: boost won't fit in that space even for all the highly useable tools that it provides.

Tarick Welling
  • 3,119
  • 3
  • 19
  • 44
2

To have it compile is the bare minimum. Notably most embedded systems are freestanding systems, such as microcontroller and RTOS applications. Compilers for freestanding systems need not provide all standard library headers, the only mandatory ones are (C17 4/6):

<float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, 
<stddef.h>, <stdint.h>, <stdnoreturn.h>

In addition, the embedded system need not support floating point arithmetic. Some systems implement software floating point support, but using that is very bad practice. If your MCU does not have a FPU, you should not be using floating point arithmetic, or you picked the wrong MCU for the task, period.

"I need to represent this number with decimals internally or to the user" is not a valid reason for using floating point. Fixed point arithmetic should be used for that. You only need floating point if you are to use math libraries like math.h and more advanced math.

Traditionally, embedded system compilers have been slow to adapt the latest C standard. It's been quite a while since C11 release now though, so at the moment all useful compilers have caught up with it (C17 only contains minor changes so we can likely ignore that one). Historically, embedded compilers have been horribly bad at this though, so remain sceptical. There shouldn't be any reason to pick a compiler without C11 support for new product development.

Summary for getting the lib to compile (bare minimum):

  • Does the library use hosted system headers, and if so does the embedded compiler support them?
  • Does the library use floating point and if so does the target system have a FPU, or at least a software floating point lib?
  • Does the library rely on the latest C standards and if so does the embedded compiler support them?

With that out of the way, you have to consider if the library is at all written to be portable. Did they take care with things like integer types, enums and alignment? Are they using stdint.h or are they using "sloppy typing" int all over the place? Did they consider endianess? Is the lib using dynamic allocation, which is banned in most embedded systems? Is it compatible with industry standards like MISRA-C? And so on.

Then there's optimizations to consider on top of that. Optimizing code for microcontrollers is very different than optimizing code for PC CPUs.

A brief glance at the various "compiler switches" (#ifdef) present usually gives a clue of how portable the code is. Looking (very briefly) at this cello lib, they seem to have considered porting between mainstream x86 systems but that's it. You would have to rewrite pretty much the whole lib if you were to port it to an embedded system. The work effort depends on how alien the target CPU is compared to x86. Porting to a high end Cortex-A with Little Endian might not require much effort. Porting to some low-end crap MCU would require a monumental effort.

Code portability is a big topic and requires very competent C programmers. To make the very same code run on for example a x86-64 and a crappy 8-bit MCU is not a trivial task.

Professional libs like protocol stacks usually come with a system port for a specific MCU, where they have not just taken generic portability in account, but also the specific system.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • 2
    `Some systems implement software floating point support, but using that is very bad practice`, nah you just need to be aware of it and that it is **slow** and indeed not needed most of the time. `low-end crap MCU` seems more inflammatory than needed and could be filled in with an actual example. (AVR/PIC/STM8) – Tarick Welling Jun 20 '19 at 14:20
  • @TarickWelling We don't do anyone a favour by pretending that 8 bit MCUs are not crap. I've been programming them forever and still maintain a fair number of them. They are all crap, no exceptions, and we all ran out of arguments for using them 10 years ago. Some of them still survive out of sheer marketing hype. – Lundin Jun 24 '19 at 06:56