Just one short year ago, developers were scratching their heads over this curiosity called Android. Today it appears developers can’t wait to get their mitts on it. Programmers and major device manufacturers alike are showing a great appetite for Android. This feeding frenzy has spilled over to the smart phone user as well. When market-research firm ComScore polled smart phone users in late summer of 2009, seven percent of current users said they would be switching over to an Android phone. A few months later, the same polling found 17 percent of the respondents were considering an Android phone.
No question the Android development platform has turned into a juggernaut. But a common concern now is that this open-source platform will become the de facto operating system for that market. And while it does show a lot of promise, let’s not forget the true and valued performance of a real-time operating system (RTOS).
General-purpose operating systems and real-time operating systems serve distinct purposes. So it’s important to first draw a basic distinction between the two.
On your desktop computer, with a general-purpose operating system (perhaps Windows or MacOS), applications are loaded and scheduled with varied results. Sometimes an application starts quickly; other times it may take several seconds to load. As a result, the user interface can often appear sluggish or unresponsive. This is because the system is busy with handling multiple tasks. While this is tolerable for the desktop (or at least we all try to tolerate it), it is unthinkable in a true, real-time embedded system. That’s what makes a real-time system deterministic: a guaranteed maximum response time to an event.
Imagine that same general-purpose system running on an embedded system in say, a missile launcher, or a robotic arm in an automotive assembly line. Certainly there will be numerous processes dependent on time-critical executions, and developers need to have an accurate understanding of these tasks. This is where an RTOS comes into play. It essentially ensures deterministic timing. That is, the amount of time taken by the operating system to respond to an instruction is constant (and small), regardless of the load, enabling it to be used in real-time applications.
An RTOS is different from the general-purpose operating systems mainly because of:
- Speed/quickness – the response times are highly predictable
- Preemptibility – it has the ability to interrupt a current thread of execution, even when it’s in the kernel, to service a high priority interrupt
- Footprint – on average it occupies very little memory
- Frugality — It consumes fewer resources, ensuring that other resources are available for more critical operations
- Version control – with a commercial RTOS you know what you’re getting, unlike with open source that has many versions that are constantly being updated
And of course, there’s the attraction of Android’s open-source licensing and its “free” software downloads. But “free” in this context has more to do with “free to design” rather than free as in no costs. Clearly, there are lines of separation between these two operating systems. Developers need to understand which OS is best given their budget, software expertise, and requirements of their application. So in a world that’s being quickly overrun by Androids, how can today’s RTOS stay competitive? Let’s take a look at a few considerations.
Necessary and Sufficient
Time-to-market has always been a key criterion for selecting an RTOS. The RTOS must be capable of meeting the functional requirements of the application. But what’s important now is to make sure the RTOS is not “overqualified” for the application. Additional capabilities can make a commercial RTOS more complicated and thus increase the learning curve for developers. All this can have a negative impact on time to market.
Many think the fastest RTOS is always best, but that’s not necessarily true.
Take memory allocation for example. You could write an algorithm to allocate memory that is really fast most of the time, or a slower algorithm that guarantees how long it takes to allocate the memory. Being fast “most of the time” isn’t real-time unless that maximum time is bounded. In some cases, the algorithm to allocate a system resource could be either really fast most of the time or deterministic.
Interrupt response, or latency, is key to an RTOS and is defined as the time from when the signal is first realized in the hardware to when the interrupt is serviced. Caching affects interrupt latency unless the RTOS takes steps to ensure the cache is either unused or is “warm” (ready for use by the interrupt handler). In some cases it may be better to turn off the cache to ensure that the cache won’t be a factor in determining the maximum interrupt latency. Better to be slow and steady than mostly faster.
Scalable, More Modular Format
Software vendors are beginning to provide modular real-time operating systems, enabling developers to include only the components they require. From small applications using minimal kernel and core services to more advanced applications utilizing available middleware, a scalable RTOS satisfies a host of wide-ranging requirements.
In the past, developers would choose between a “light” RTOS or an “advanced” RTOS depending on the application’s requirements. Today, the choice isn’t so easy. While minimal configurations (the light RTOS) might appear more attractive, as applications become more complex, developers invariably end up writing more code to fill the gap between what the RTOS offers and what the application requires. This can lead to more engineering time, additional engineering costs, and even delays in time-to-market. A better approach may be to utilize an RTOS that has all the functionality you may want or need and strip out what you don’t.
Evolving to a Linux-Based RTOS?
Speaking of modularity, Linux-based RTOSs definitely deserve a mention. There are a number of vendors who have taken the basic Linux distribution and altered it in their own way to achieve real-time performance.
Will the Linux-based RTOS hurt, or even replace, the commercially available RTOS? Only time will tell. It’s incumbent upon the developer to fully realize the difference between the contractual agreements of a commercial RTOS and what is perceived to be “free” software downloads and the commitment one makes to the open source community. How much time do you want to spend writing code? How much money do you want to spend? In many respects, this hybridized RTOS approach might just come down to the classic build-versus-buy dilemma.
Royalties to Services
The open-source movement has shined a new light on “services,” and, as a result, the concept has gained widespread acceptance. Many traditional OS vendors are shifting from a royalty-based revenue model to a support- and services-based model, or a combination of the two. This is becoming evident throughout the embedded software space. For instance, Mentor Graphics now offers Android platform-development support services.
Adapting to Multicore and Virtualization
Recent trends in the industry that affect the use of an RTOS include multicore and hypervisor technologies. While multicore operating systems have been around for some time, serious advances have been made in the embedded space. Most of today’s RTOSs can be used in multicore development as long the selected RTOS is capable of shared memory communication, has integrated on-chip I/O support, offers intelligent cache-utilization strategies, and is capable of performing inter-core interrupts, multithreading, and multiprocessing. Today’s chips now have multiple cores. As more cores are built onto a single chip, software challenges will intensify. Having an operating system that handles basic symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) will enable greater flexibility.
Hypervisor technology, at its most basic level, can be thought of as another name for virtualization. It is a “virtual machine monitor” that can be implemented at either (or both) the hardware and software levels to enable multiple operating systems to run concurrently. Virtualization is essential to ensure full CPU utilization in a multicore system.
The system that uses a hypervisor must be provisioned by defining what system resources go to a particular operating system. Are there any shared memory regions or devices that must be shared between operating systems? What about running multiple operating systems on a single core? It’s important for the hypervisor take care of the real-time needs of one operating system while not completely starving the other operating system. Most importantly, are there any real-time events that the hypervisor must adhere to regardless of what operating system is scheduled?
Conclusion
While Android is gaining in popularity, there are still plenty of systems that must be deterministic. And time spent making Android or another operating system more compliant will only eat into time-to-market. The RTOS has its place and will continue to thrive in minimally configured, deterministic devices.
As hardware continues to increase in complexity, it may be tempting to jump to a general-purpose operating system, and that may be the right answer for some, but others must realize that the RTOS may be exactly what is needed. A better approach may be to partition the system in such a way that it can run both an RTOS and a general purpose operating system.
Perhaps not as sexy as Android, the embedded RTOS deserves recognition and consideration for what it has accomplished up to this time. The RTOS and a general purpose OS such as Android should not be viewed as adversaries, but rather as very strange bedfellows indeed.
Author biography
Stephen Olsen is a technical marketing engineer for the Mentor Graphics Embedded Software Division. He has over 20 years of embedded software experience with the past 14 years spent at Mentor Graphics. During his tenure at Mentor, he has co-chaired VSIA’s Hardware dependent Software (HdS) design working group and authored several papers on system design and power management. Stephen has worked in consulting, system architecture, embedded software, and IP. He holds a BS in Physics from Humboldt State University in California. He can be reached at stephen_olsen@mentor.com.
