Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
    
I'd have assumed that using Linux on an embedded device would require a pretty minimal kernel too? Indeed, for embedded and especially real-time requirements you may not even be allowed use some of the things you think you gain by using Linux. –  James Aug 26 '12 at 18:12

2 Answers 2

  1. Portability
  2. Threading support
  3. There will be fewer bugs if you reuse mature OS code than if you replace parts (e.g. device drivers) of the OS with your own code.
  4. Much, much easier to get/make the C libraries.
  5. Much easier to find answers to problems if you use a popular OS like Linux.

Having said that, if I was the guy that you were trying to convince I would not be impressed if you told me that you could get the exact same performance that you can get with bare-metal code. That's nonsense.

You could, on the other hand, convince me that the differences would be small enough that it would not matter for the particular application, or even that the differences would matter but the advantages of the OS are significant enough that it would still be worth it. Acknowledge that there will be differences, though. If you don't, why should he trust your analysis?

share|improve this 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.

share|improve this answer
    
Pretty much all RTOS used to operate with a flat memory space without protections, because most of them were initially developed in the days when such things were simply not available or affordable on most embedded hardware. They were a thin service layer for the application - not really a full OS like Linux. –  Michael Kohne Sep 25 '12 at 13:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.