Linux vs Bare Metal – Advantages of Programming Under an OS

embedded-systemslinuxoperating systems

Assume you are presented with an embedded system application to program, in C, on a multi-core environment (think a Cavium or Tilera) and need to choose between two environments:

Code the application under Linux in SMP mode or code the application under a thin bare metal executive (something like a very minimal RTOS), perhaps with a single core running UP Linux that can serve control tasks.

For the purpose of this question, assume that both environment provide the same level of performance guarantees in any measurable aspects of run time performance, including number of meaningful action per second, jitter, latency, real time considerations – the works. (and yes, I realize this is by far not a trivial assumption at all, bare with me).

How would you justify going with a Linux SMP based solution rather then a bare metal thin executive solution?

The question may seems silly. It certainly seems obvious to me – but I have to convince someone that does not think the same. Could you help make a list of arguments in favor of choosing a real SMP aware OS (Linux) vs. a bare metal executive assuming performance guarantees are NOT an issue?

Many thanks

Best Answer

Some initial advantages include:

Code safety because the operating system can enforce memory protection and run some tasks in supervisor mode and others in user mode. A few years ago when I had a class for a very popular RTOS I was shocked to see it used a flat, shared memory space. Not sure if this is common, but it seems like a big jump backward.
Availability of wide ranging support for many peripherals through drivers.
If a device is not available, a driver can implement just the functionality needed to fit with a corresponding stack, rather than everything that goes with having the device. Typically at least one similar device will have been written and can be used as an example.
There may be compiler or library level support for thread safe support for Linux. If you have an executive, you may lack this and you may need to provide it yourself. If the executive has an active user base, there may be a combination of libraries available for purchase or via open source, but the quality may depend on how wide and deep the support that community provides. Pick your community with care.
If you start without all the baggage that comes with a real operating system, how long until you can't get along without those extra features? Who writes, integrates, and maintains them?

Hope this helps.

Related Solutions

RTOS vs Bare Metal – Benefits for MCU Programming

Microcontroller programs consist of a number of tasks. Let's say you wanted to make a computer-controlled telescope mount. The tasks would be:

Retrieve a new byte of input from the USB serial buffer.
Check if we've received a complete command.
If so, execute that command.
Read the sensors for the current telescope position.
Set the proper output to control the next step of the motors.

This is a fairly typical set of tasks for something you would use a microcontroller for, and are pretty easy to manage with an infinite loop, like:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

If you keep adding and adding features, you eventually start coming across common problems you want to create abstractions for, like:

Your buffer is overflowing, so you want to make sure that task can interrupt other tasks before it overflows.
You want to save battery by sleeping when nothing is needed.
You want to make sure all tasks get a fair shot. If readSensors takes too long, you want to be able to interrupt it and come back to it later.
You want to be able to just reset one task without affecting others.
You want a memory leak or other bug in one task to not take out the other tasks.
You want to be able to give different tasks different priorities.
You want to be able to sandbox an untrusted task.
You want to be able to execute tasks at different rates. Perhaps your sensors can only be read 10 times per second, but you want to execute a motor step 100 times per second.

One or two of these items can be handled manually relatively easily. If you have enough of these kinds of problems frequently enough that you start generalizing them into libraries, you've basically reinvented an RTOS. If your program's task management is complex enough, even if you don't use an off-the-shelf RTOS, you will eventually end up reinventing one poorly.

However, in my experience, the line where you want an RTOS is very close to the line where you want a microprocessor instead of a microcontroller. If you anticipate your firmware getting that complex, it's usually better to go the microprocessor route from the beginning.

Java – Cross-compiling Java app to run directly on ARM

You can compile Java to binary for a target using LLVM. A quick look at the docs shows support for many ARM variants.

https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt

Also another stack-overflow style answer in this vein at

https://stackoverflow.com/questions/10804280/is-there-a-llvm-java-front-end-that-converts-java-source-to-llvms-intermediate

Best Answer

Related Solutions

RTOS vs Bare Metal – Benefits for MCU Programming

Java – Cross-compiling Java app to run directly on ARM

Related Topic