general purpose libraries suitable for embedded c??

[Chendy]

Hi all,

I'm actively trying to get more into embedded, seemingly C is the way to go for say arm cortex M4. I have done a number of basic embedded projects over the years, but using a hobbyist approach.

What I'm trying to understanding is typical professional embedded c coding cultures. My current question in that regard is the extent to which libraries are used, vs coding everything from scratch each time or I guess a murky middle ground of maintaining a personal / small team set of libraries.

In say Python, there are large professional grade libraries, so that its unlikely you should every really do basic programming building blocks yourself.

1. what are peoples thoughts on where people typically may use a library vs code from scratch? say for writing some basic dsp for arm cortex m4

For example, this may seem silly... but I want to know if there exists libraries that do simple yet recurring things such as
   * bit masking, setting individual bits... bitarrays etc? library macros?
   * say finding the max value of an array? perhaps using an embedded safe similar datatype similar to raw array, suitable for cortexM4 dsp

I'm hoping I can stand on the shoulders of giants vs re-invent to wheel using my noob skills.
 
For more complicated things, like TCP/IP or DSP (CMSIS-DSP) I know libraries exist.

2. Beyond these examples, what libraries do people use for embedded that may be useful to me to explore?

Many thanks

[donotdespisethesnake]

Depends on your goal. For hobbyist or art installations, plugging together code blocks Arduino style is a quick way to get something working. However, for professional applications you need a thorough understanding of embedded coding, even if you are using existing code blocks.

I would look at writing code from scratch first. Then later you can try integrating code such as LWIP into projects.

[dmills]

For things like bit twidding I am confused as to why anyone would want a library, C is **GOOD** at that stuff, I might write a macro but that is highly situation dependent and only sometimes makes the code clearer.

Sure I could write a macro pair something like

BIT_SET(t,b) (t |=(1u <<(b)))
BIT_CLEAR(t,b) (t &= ~(1u <<(b)))

But is
BIT_SET(PORTB, LCD_EN_BIT)
BIT_CLEAR (PORTB, LCD_EN_BIT)

actually any clearer then

PORTB |= LCD_EN;
PORTB &= ~LCD_EN;

I am not sure the macro version is really much of a win.

You see library code used for things like USB and TCP/IP stacks which are inherently big enough projects to make the time spent learning the library less then the time spent writing it from scratch, but for the trivial sorts of peripheral (SPI, I2C, PWM and such like trivialities) one usually writes their own or has a house collection of useful fragments.

Very often such 'libraries' are really just a C file and a header that you build into your project.

The issue is that there is just a lot of project to project variability, sometimes you want interrupt driven, sometimes a polled state machine, sometimes DMA is indicated, and if you need one style, the others are really no good to you except as reminders of register names.

There have been tries at embedded frameworks, There is that ST thing and Microchip "Harmony" springs inexorably to mind, they tend to be universally despised.

Certainly for DSP, all the vendors have their own examples of how to write things like FIR convolutions in the way that best suits their particular chip and compiler, and not only are they all different, but the memory alignment requirements going in are also all different.... DSP pretty much has to be specialised.

Regards, Dan.

[Kalvin]

The first question is what do you mean by embedded, There are systems with MCUs with extensive memory resources, and there are systems with very constrained MCUs with very little memory. In addition to this, some systems are very timing-constrained, so that will typically limit the usefulness of the readily available libraries. Sometimes the safety requirements or other requirements limit the use of available libraries.

If you have a MCU with plenty of RAM and FLASH to spare and no special timing requirements you basically can use whatever libraries you want and you find useful. For example the ARM Mbed, Arduino and similar frameworks provides good set of general purpose libraries that are very useful.

However, if you have a MCU with very little RAM or FLASH you have to be careful how well the libraries are written in terms of memory footprint. Typically you take an existing library and handcraft the code for the purpose in order to minimize the memory consumption. Or, you can also write it from the scratch as this may be the faster way to achieve the requirements.

In the timing constrained code, you have to be very careful with the existing code and libraries, so you need to analyze and test the code throughly before you start using the code. You may need to tweak the existing source code for needed performance.

In some cases the libraries may use dynamic memory allocation (malloc / free etc.) or other implementation practices which may not be compatible with your requirements, which may limit the usability of the available libraries.

In all cases you have to analyze the quality, the reliability and the suitability of the available libraries for your project.

[Chendy]

thanks, gonna take some time to digest this, but quickly .. @Kalvin what im not talking embedded linux, but embedded MCU ... "say for writing some basic dsp for arm cortex m4" beyond the DSP library code of course!

[Kalvin]

thanks, gonna take some time to digest this, but quickly .. @Kalvin what im not talking embedded linux, but embedded MCU ... "say for writing some basic dsp for arm cortex m4" beyond the DSP library code of course!

Me neither I was writing my reply regarding typical embedded system which is running on bare-metal or very simple OS. For DSP on Cortex M4: Typically those algorithms are handcrafted for the purpose using the basic signal processing blocks available from the compiler vendor which will generate most efficient code:

http://www.keil.com/pack/doc/CMSIS/DSP/html/index.html
https://developer.arm.com/technologies/dsp/dsp-for-cortex-m

The source code has to written in certain, compiler specific way so that the compiler will be able to generate optimized code from the source code. It is possible that there are somewhat generic libraries available, but as I stated before those libraries tend to be quite compiler specific and architecture specific at least.

[rstofer]

I don't deal with DSP but other applications I try to avoid using anything other than the required C library.  I will make every attempt to avoid having to implement a heap.  I use the code from "The C Programming Language" for all my conversion functions.  I don't use printf() or any other function that may require a heap.  Specifically, sbrk() won't be defined!

Some of the C library is unavoidable because it includes things like multiplication and division.  But I sure don't have to #include <stdio.h> or any other .h files not a part of the project.

That works fine for small projects but as soon as I get a project requiring TCP/IP, all bets are off.  There are thousands of lines of code and I don't plan to rewrite it any time soon.  I just hope for the best!

[nctnico]

I don't use printf() or any other function that may require a heap.

printf doesn't use heap memory. I strongly recommend not to create your own string printing versions but use a minimal printf instead.
The older versions of MSPGCC have a very small C library. It is a good idea to keep your programming environment POSIX compliant so you can use other people's code more easely.

[Howardlong]

A quick comment on the Cortex M4 CMSIS DSP library, please be aware that not all the functions are optimised!

[hamster_nz]

...so that its unlikely you should every really do basic programming building blocks yourself.

My current little project is a case in point. I'm interfacing a GPS module to a small Raspberry Pi, and maybe to move to microcontrollers (e.g. ESP32)

Options:
- Use GPSD
- Use a GPS library
- Use Python to cut apart NEMA sentences, reading a line at a time from the TTY
- Use C to cut apart NEMA sentences, reading a line at a time
- Write a FSM to parse NEMA sentences, a character at a time.

I'm doing the latter - why?

- The memory requirement is much lower - unlike if somebody sends a million "A"s when you are processing a line at a time, you only need to hold the FSM state and working values.

- I can move the code to small processors quickly and easily. I can't with a Python library (yes, I know that micropython exists)

- When on the micro I can call the FSM with each character from a serial port interrupt handler, so it becomes an invisible service to application (although the app has to detect when the GPS data goes stale with a timer).

[westfw]

printf doesn't use heap memory.

The newlib nano library (very commonly used with gcc-based ARM toolchains) seems to end up using the heap for printf().
I don't know whether it's printf() itself, or the stdio code that gets sucked in to implement the filesystem layer below printf().

https://community.atmel.com/comment/2374621#comment-2374621