Requirements to be embedded friendly

Brainstorming
1

When writing a library that should be suitable for embedded applications, what is required?

I can think of:

  1. Use the allocator interface for all allocations.
  2. Timers?
  3. Mutexes?
  4. Threads?
  5. Accept interfaces for all syscalls so embedded can provide their own implementation? (Sockets etc)
1 Like
2

What embedded architecture/platform are you targeting?

If I’m not entirely mistaken, or remembering it wrong, NASA for example does not allow dynamic memory allocations even if the architecture allows it.

EDIT:
Here’s a link to a list of NASA rules.
https://en.wikipedia.org/wiki/The_Power_of_10%3A_Rules_for_Developing_Safety-Critical_Code

1 Like
3

My understanding is the NASA power of 10 is more targeted towards human safety or mission critical code.

I’m talking more generally about writing libraries that can be re-used when targeting embedded platforms, something ARM cortex or similar without and OS.

4

ARM is not the only embedded CPU. How many cores does the CPU have?

You don’t seem to address the issue of memory size etc at all. There is no one universal “this is good for ALL embedded systems” answer.

What’s your background? Knowledge of computer architectures, etc?

5

Well, many embedded systems share a thing. I think he wants to build a library you can use on as many embedded systems as possible.

So you’ll have to build probably an own allocator for an embedded system (or use FixedBufferAllocator) etc. if you want to use that library on a new embedded device. But using, for example, the GPA in a library isn’t a good idea, as many embedded systems don’t even use a kernel (raspberry pi pico, arduino, …) and the GPA needs some system calls.

In my opinion, (1) is mandatory. (2), (3), (4) and (5) depend on the type of library. If you write a multi-threading library, it’d be a good idea to support custom thread interfaces…

4 Likes
6

Embedded is a broad church, ranging from tiny microcontrollers with tiny footprints all the way up to complex real-time multimedia or industrial type systems.

What they all have in common is that they have some kind of time, CPU or memory constraint and they do not have traditional user controls we expect from a computer.

My work is mostly on 32bit microcontrollers for networked consumer products.

When I’m picking a library for my embedded projects, I’m looking for:

  • Portability, I probably need to run it on the target device and in some kind of simulation environment too
  • Asynchronous APIs. There is likely already a main loop in the system handling IO, so I will want to call the library when needed - not have it control the system
  • Well defined footprint. Control over how much RAM/ROM space it is going to use
  • No/limited dependencies. Most of my embedded work is in C and we rarely have a full C standard library to call on. Sometimes there is no heap memory allocator.
  • No/limited OS dependence. On a baremetal system there may be no support for threading or timers so any support for specific APIs needs to be optional
  • A non-copyleft license. I do commercial embedded work where clients would not accept GPL licenses or statically linking to LGPL code
7 Likes