Useful C frameworks / libraries for embedded development generally?

[Chendy]

Hi gang,

Do people use or know of any frameworks / libraries appropriate  for micro-controllers, which contain useful functions so one doesnt have to re-invent the wheel? I have no specific use case in mind, but given Im dont use and am not aware of any, thought this might be an area worth exploring.

There is this question on stack overflow, but hasnt got much responses:
http://stackoverflow.com/questions/12842265/c-library-for-common-realtime-embedded-tasks

and googling gets me:
https://github.com/edenhill/librd

But more keen to hear if people have actual experience on this

Im guessing people mostly build up their own personal libraries

Cheers

[dannyf]

Wouldn't that be mcu specific?

[nctnico]

The standard C library is pretty usefull. After that a USB stack, ethernet stack, FAT filesystem may come in handy. Manufacturer supplied libraries for handling simple peripherals usually suck really bad so it is better not to use those.

[hans]

Frameworks or libraries for embedded is hard, because the underlying hardware changes so much.
Additionally there is no room for the same amount of overhead a desktop PC driver model has. Timing constraints does not allow this to happen in all cases.

Thus usually what happens is a library of standard protocol stacks and driver code is built, from which applications are made.
For me some of this is self written, some is familiarized code like lwIP or some USB stack.

Going by the list of the stackexchange post:

- Timers:
Is different on each chip family or architecture.
You can write your own abstractions for each MCU but generally the code that will be using MCU hardware is also hardware or platform specific.
If using software timers from a RTOS, it still changes between RTOS unless you program to CMSIS standard (however, not every platform has a CMSIS RTOS)

- Speed optimized maths:
Can depend on hardware and on what kind of math. E.g. 16-bit integer math will run faster on a 16 or 32-bit CPU than on an 8-bit CPU.
Floating point can be accelerated with FPU hardware on the CPU.
Some libraries are written better than others..

- Checksum:
Some microcontrollers have hardware acceleration, but not for all types of checksum.
I like to keep a library of fallback software routines for this. Then it is a matter of some build script tricks to change from software to hardware implementation.
The same can be said for encryption. Software encryption is very slow on a microcontroller; but it can be done if necessary.

- Protocol stacks:
USB is specific to the MCU you program on. Unfortunately almost all USB libraries I have come across merge the enumeration, EP0 setup handler and USB hardware endpoint handling in 1 blob of code. I'd love to come across a lwIP-alike USB stack in which you just change the packet engine. That way all USB class and vendor specific drivers can be equal and ported across hardware.

Other protocols in my experience are more freely to move. Ethernet stacks work rather simple.. the TCP/IP stack consumes frames and produces frames, and probably needs time awareness to handle TCP timeouts. There is little extra communication to the hardware or phy necessary. Again some stuff can be tuned in configuration, e.g. some chips will have IPV4 and TCP hardware checksum calculation.. that will yield better performance.


Again I usually grab stuff from my own code library because I know how it works and what is needed to drive it. I add when needed for a new project.
Alternatives could be learning to work with other frameworks like Contiki, however some of these frameworks are application specific (in this case IoT).

[rstofer]

If you look around here, you will find a thread or two or three complaining about the CMSIS package for the STM32F processors.  In fact, it probably won't take much searching to find similar complaints about ALL CMSIS packages.  They are at least twice as much work as writing your own code.  In either case, you need to totally understand the datasheet.  To which CMSIS requires you find and understand that documentation and, in all likelihood, you will need to review every aspect of the code to look for conflicts with your hardware design.

I agree that generic RTOS, USB and TCP/IP code should be used at every opportunity.  But these are a level up from the raw iron and can be essentially hardware independent.  Something like lwIP only requires the user to implement the hardware driver code.  All of the network details are handled.

[mark03]

I've used Miro Samek's QP framework (www.state-machine.com) several times for statechart-based design. (See D. Harel, Statecharts: A visual formalism for complex systems).  It's not appropriate for every embedded application, but I've seen plenty of spaghetti-code superloops which would have benefited from an event-driven programming model.  Dual licensed GPL or closed-source proprietary for a fee.

[richardman]

Our business is to start providing such a framework, starting with the low level peripheral subsystems support ("JumpStart API" for STM32F), and moving to RTOS, USB, TCP/IP in the near term. This is for use with our commercial tools, currently closed source (which may or may not change later).

I will not say any more else making this too commercial. Any way, anyone interested may check out our website (link on my signature) or contact me. I am actually quite interested in discussing generic design issues related to these aspects.

[nctnico]

- Protocol stacks:
USB is specific to the MCU you program on. Unfortunately almost all USB libraries I have come across merge the enumeration, EP0 setup handler and USB hardware endpoint handling in 1 blob of code. I'd love to come across a lwIP-alike USB stack in which you just change the packet engine. That way all USB class and vendor specific drivers can be equal and ported across hardware.

AFAIK LUFA (and the USB stack derived from it by NXP) does that. It has seperated the hardware layer from the USB stack itself.

[Sal Ammoniac]

Except for really complex stacks like USB I prefer to roll my own peripheral libraries for MCUs.

That way I know the code intimately and only implement features that I need and use. A good example of the latter is the I2C driver in the STM32F4 HAL. It's over 5000 lines. My own driver is 487 lines.

[dannyf]

"you will find a thread or two or three complaining about the CMSIS package for the STM32F processors. "

I havent seen any real complaints about the cmsis package forr any chip.

Ibhaave seen plenty of complaints about the various vendor implementation of peripheral drivers, often unrelated to the cmsis.

I have seen a few mistaken complaints about cmsis when in fact they were complaining about the vendor stuff. Those people are simply too confused to understand thee differences between cmmsis and vendor libraries.

[donotdespisethesnake]

Our business is to start providing such a framework, starting with the low level peripheral subsystems support ("JumpStart API" for STM32F), and moving to RTOS, USB, TCP/IP in the near term. This is for use with our commercial tools, currently closed source (which may or may not change later).

I will not say any more else making this too commercial. Any way, anyone interested may check out our website (link on my signature) or contact me. I am actually quite interested in discussing generic design issues related to these aspects.

Wow, more spam from you. You are really desperate to plug your stuff aren't you?

Please, if you want to advertise, buy an ad, stop polluting discussion threads.

[rstofer]

"you will find a thread or two or three complaining about the CMSIS package for the STM32F processors. "

I havent seen any real complaints about the cmsis package forr any chip.

Ibhaave seen plenty of complaints about the various vendor implementation of peripheral drivers, often unrelated to the cmsis.

I have seen a few mistaken complaints about cmsis when in fact they were complaining about the vendor stuff. Those people are simply too confused to understand thee differences between cmmsis and vendor libraries.

True, the framework for CMSIS is elegant but it is the implementation (vendor stuff) that bites.  It also depends a great deal on how far up the foodchain the device is.  For the small ARM7-TDMI devices, all this stuff is overkill (I don't think I have seen CMSIS for the ARM7-TDMIs, I first ran into it with the STM32F).  It just isn't that tough to come up with peripheral drivers.  Moving up to the dual-core fully loaded processors with FPU, MMU and caches, perhaps it is better to use the library.  But you're relying on the other guy to get it right!

http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

[frankpurter]

Apache Mynewt is permissively licensed (Apache 2.0) and written in C. Apache Mynewt includes a flash file system ('nffs'), lightweight TLV storage mechanism, circular buffering schemes, secure boot loader, logging infrastructure, and an open source Bluetooth Low Energy stack.

http://mynewt.apache.org/

It looks like more network protocol stacks are coming.

[Howardlong]

Except for really complex stacks like USB I prefer to roll my own peripheral libraries for MCUs.

That way I know the code intimately and only implement features that I need and use. A good example of the latter is the I2C driver in the STM32F4 HAL. It's over 5000 lines. My own driver is 487 lines.

This.

The problem with abstracting the simpler peripherals is that "frameworks" (God, I hate that word!) or more generically peripheral libraries try to be a jack of all trades but master of none. As new hardware comes out with new features, the APIs are rarely fit for purpose, so they change and you lose backwards compatibility.

Then, of course, every few years, the vendor will re-invent their APIs. 

Much more key is that you have little choice anyway but to understand reasonably well how the hardware works, so you might as well write and test your own.

It's also not at all unusual for APIs to have bugs in them, and to correct them you'll often have to hack the vendor libraries leading to version control nightmares.

USB and Ethernet, nah, I just suck up the vendor libraries, but there are brave souls out there who hack stacks onto bare metal, but that's not my idea of fun.

[Red Squirrel]

I have not explored too deeply into this but it does infact seem to be something that is lacking.  I ended up just going the Arduino route.  I program the chip directly, but with the Arduino IDE and it's libraries.   It seems to be hard to find info on how to code MCUs natively, you can find code snipplets here and there in the datasheet and online, but nothing as extensive as Arduino    I eventually may want to move to learning other chips too, like ARM and such, but for now Atmega will do.

[richardman]

I presume you are referring to the AVR when you said "It seems to be hard to find info on how to code MCUs natively.." The thing is that with a simple processor like the AVR, then once you figure out the basic thing like how to write to a port, e.g. DDRC = 0xFF; then the rest really is "what do you want the IO registers to do? For the AVR, there is hardly any point of providing a "Peripheral Abstraction Layer" as something like "Turn on LED at PortB pin 5" is just "PORTB |= (1 << 5);"

For the beginners, Arduino is good because it hides the bit operations, but otherwise, it's mainly just fancy names, and you can go from coding with Arduino functions to native code quite simply.

There's a separate issues of "how to write embedded programs" but that's more generic. Then it's a matter of learning IO principles, communication protocols, RTOS etc. There is where libraries could come in handy. In a commercial situation, I doubt many companies will let their engineers write their ow USB stack when there are open source and commercial versions available.

I have not explored too deeply into this but it does infact seem to be something that is lacking.  I ended up just going the Arduino route.  I program the chip directly, but with the Arduino IDE and it's libraries.   It seems to be hard to find info on how to code MCUs natively, you can find code snipplets here and there in the datasheet and online, but nothing as extensive as Arduino    I eventually may want to move to learning other chips too, like ARM and such, but for now Atmega will do.

[hans]

- Protocol stacks:
USB is specific to the MCU you program on. Unfortunately almost all USB libraries I have come across merge the enumeration, EP0 setup handler and USB hardware endpoint handling in 1 blob of code. I'd love to come across a lwIP-alike USB stack in which you just change the packet engine. That way all USB class and vendor specific drivers can be equal and ported across hardware.

AFAIK LUFA (and the USB stack derived from it by NXP) does that. It has seperated the hardware layer from the USB stack itself.

Nice find, it does seem the code is set up in a structured manner that allows that. At least, I was able to find drivers for ATMEGA, ATXMEGA and UC3 processors.

The NXP port seems to be quite old, but shows it can be done.

I wonder how porting LUFA to e.g. STM32 or PIC32 will stand up license wise. Because LUFA stands for "Lightweight USB framework for AVR"..

[CustomEngineerer]

I have not explored too deeply into this but it does infact seem to be something that is lacking.  I ended up just going the Arduino route.  I program the chip directly, but with the Arduino IDE and it's libraries.   It seems to be hard to find info on how to code MCUs natively, you can find code snipplets here and there in the datasheet and online, but nothing as extensive as Arduino    I eventually may want to move to learning other chips too, like ARM and such, but for now Atmega will do.

Not sure if this is exactly what you are looking for, but Miro Samek (of state-machine.com, mentioned above by mark03) has a free online tutorial course on getting started with embedded systems programming, http://state-machine.com/quickstart/. He uses the Texas Instruments Tiva-C LaunchPad (can be gotten from TI for about $12) which is a Cortex M4F based microcontroller. He teaches how to get a free development environment set up and then how to program directly as well as using vendor libraries and the CMSIS, and how to debug whats happening (the Tiva-C makes this easy, has a second microcontroller on the board which allows you to hardware debug through a USB connection, which means you don't need to by an external programmer/debugger). His videos are what got me back interested in programming and electronics in general several years ago. Each video is about 15 - 20 minutes long, all code and video notes are available for download so you can jump around in the series if you want (though each lesson builds on the previous). It looks like the first video in the series was released in Jan 2013, and a new video comes out every couple of months.

Edit: Forgot to mention, the videos themselves are on youtube. https://www.youtube.com/playlist?list=PLPW8O6W-1chwyTzI3BHwBLbGQoPFxPAPM

[Red Squirrel]

Cool I will have to check that out.

[ez24]

Not sure if this is exactly what you are looking for, but Miro Samek (of state-machine.com, mentioned above by mark03) has a free online tutorial course on getting started with embedded systems programming, http://state-machine.com/quickstart/. He uses the Texas Instruments Tiva-C LaunchPad (can be gotten from TI for about $12) which is a Cortex M4F based microcontroller. He teaches how to get a free development environment set up and then how to program directly as well as using vendor libraries and the CMSIS, and how to debug whats happening (the Tiva-C makes this easy, has a second microcontroller on the board which allows you to hardware debug through a USB connection, which means you don't need to by an external programmer/debugger). His videos are what got me back interested in programming and electronics in general several years ago. Each video is about 15 - 20 minutes long, all code and video notes are available for download so you can jump around in the series if you want (though each lesson builds on the previous). It looks like the first video in the series was released in Jan 2013, and a new video comes out every couple of months.

I added the above link here

https://www.eevblog.com/forum/beginners/electronics-primers-course-material-and-books/?action=post;last_msg=959288

thanks