It is unusual for a modern embedded design, with any degree of sophistication, to be implemented without an operating system of some sort. There are plenty of reasons for this: scalability of the multi-tasking model, availability of standard software components (IP – like drivers, protocols etc.) and the fact that the majority of developers are most comfortable programming in an OS-supported environment. This means that an early decision to be made is which OS to utilize.

OS selection is quite a large subject and there are many nuances, and this is a matter that I have written about many times. Today I wanted to ponder the matter of time; what model of time is relevant to the application?

Broadly, embedded applications are real-time, which means that they respond to an external event in a deterministic (i.e. predictable) manner. A delay in such a response would be deemed a system failure. Similarly, a real-time system may initiate activity at predictable times. A non-real-time system does not have such time constraints. A real-time system is not necessarily fast; it is simply fast (or slow) enough to meet the specification for responsiveness. Likewise, a non-real-time system is not necessarily slow; its response is just not deterministic.

It is largely accepted that a real-time system is best implemented using a real-time operating system (RTOS – the name gives it away!). RTOS products are designed to facilitate the implementation of a deterministic application. For a non-real-time application, as RTOS could still be used, but the fine control of time may be overkill and there are some attractions to using operating systems like Linux, if resources (memory, CPU power etc.) permit.

Increasingly the world is not that simple. Real-time systems are commonly categorized as being “hard” or “soft” real time. This qualifier refers to exactly how tight the time constraints of the application specification are. Hard real-time means very tight response time requirements; soft real-time means they are much laxer.

An RTOS is certainly the right choice for hard real-time and could be used also for soft real-time. However, if the hardware is fast and provisioned with plenty of memory, running Linux might be fine for a soft real-time application. The code will not, strictly be “real-time” at all, but, if it is running sufficiently fast, it would normally meet the response time requirements.

Designing a system like this sounds slightly haphazard and a purist engineer might be appalled. However, it will do the job quite satisfactorily, even if the implementation is essentially gross over-kill. Sometimes, there are demands on a project – such as time to market – that necessitate this kind of approach, which comply with Voltaire’s advice: “Do not let the perfect be the enemy of the good.”

It is possible that, in coming years, we shall see the appearance of intermediate forms of OS – somewhere between real-time and non-real-time, but I am cautious about making predictions. I recall an experienced and knowledgeable colleague explaining the future of embedded operating systems to me about 20 years ago. He said that, well within 5 years, there would only be 3 real options: X, Y and Z. Of these, only one is still visible in the market and that is definitely on the wane and the other two have long since disappeared. I do not own a crystal ball ...

Colin Walls is an Embedded Software Technologist in Mentor Graphics’ Embedded Software Division.