Spend a few minutes at your local electronics store and it's obvious — the mobile phone is a device that far surpasses its original intent. With respect to functionality, today's mobile phone goes well beyond the ability to make calls and store phone numbers. It also synchs up with your desktop's calendar and address book, it can take pictures, play and store music, and receive emails.

ImageThis is technology convergence at its finest. But the mobile phone isn't the only device experiencing this new age of enlightenment. Cameras take pictures and record movies with playback sound. Personal media players play music and movies, track your calendar, and store photos. And don't get me started on convergence in the automotive arena. Developers of today's products are encouraged to take advantage of every piece of technology available to them.

This type of convergence comes in two very different packages: "easy to carry" and "easy to use." Easy to carry packages are resource limited because the entire unit is portable and constrained in regards to footprint and power consumption. Conversely, easy to use packages are comparable to your desktop. They have an easy-to-use graphical user interface and are not constrained by power consumption or packaging.

The goal of the portable device developer is to create powerful, useful, and engaging devices that are both easy to use and have "acceptable" portability. As with the massive convergence mentioned above, the end user's perceptions of acceptable portability is also stressing the manufacturers' abilities to meet ever more demanding usage criteria. Manufacturers are increasingly pressured to put more functionality into smaller packages while trying to extend battery life further and further. The challenge for device manufacturers is how to balance the needs of the user with bleeding edge technology while maintaining a competitive price point.

This is where a full-featured operating system (OS) comes into play. A good OS provides the interface to the hardware and allows the device to be managed in the most efficient manner possible. If the OS is managing both hardware and software, how can it possibly stay responsive? The answer lies in the real-time capabilities of that particular OS (see figure). A real-time OS keeps responsiveness at the top of the requirements list.

We all know developing a real-time kernel is no great feat. But once you start adding on all the components that make a full-featured operating system, real-time responsiveness has the potential to get lost in the clutter if the system is not architected from the start to provide real-time performance. With that in mind, let's take a look at a few examples of operating system components that comprise a full-featured OS and how the lack of real-time features can affect the overall responsiveness of a device.

File System

Perhaps the most basic component of any operating system is the file system. It is here where multimedia content such as images, music, and movies are stored. Databases of contacts, calendars, and emails are also kept in the file system. In portable systems, the key is fast flash memory, which means a clean, slick profile. To remain practical, however, the file system must be implemented so that it does not corrupt the data in flash if power is lost while writing to a file. These file system traits are standard with most full-featured operating systems.

A requirement of an embedded full-featured OS, obviously, is to run in real-time, storing and retrieving files in a fashion that does not disrupt system processes. A sure sign of this disruption within a multitasking based system is the disabling of interrupts. When you disable interrupts you're opening the door for latency in the system. If interrupts are disabled, other external input is also unavailable. Whether this external input is a key stroke on a phone, or a flat line from a medical device, the system won't receive it until the interrupts are enabled again. While operating systems — both real-time and non real-time — disable interrupts, real-time operating systems do this in the most efficient, unobtrusive fashion possible. A real-time file system does institute locking mechanisms to manage multiple tasks accessing the file system simultaneously, but also does it according to task priorities that are assigned so that the most important tasks and operations usually have a first crack at a resource when it is available.


Increasingly, devices today are "connected" devices. Whether through a wired or wireless interface, the objective is the same — provide network connectivity. From browsing the Web to streaming audio and video, a network connection allows the end user to take full advantage of a device's multimedia capabilities. From phone calls to bank transactions, the Internet is now enabling some of the most common routines.

Basic Web browsing does not take a large amount of network resources. A request is sent from the device to the Web server and files are sent back to be viewed by the user. If that page is to stream video content, however, quite a bit of networking traffic is generated. As with a phone call, the voice or video stream will inundate the device with networking packets. There are three outcomes to this:

  1. there is enough processing power to handle this stream;
  2. the OS has measures already implemented to handle this situation; or
  3. the device slows to a crawl.

If there's enough processing power to handle the stream, the end user will not notice disruptions of any kind. But having this type of processing power in a smaller device usually means a higher price of goods gets passed down to the end user along with a shorter battery life, which is why this is rarely a wide-spread solution for most mainstream connected devices.

If the operating system is tuned from the start for embedded real-time operation, it will be more responsive in its environment. One reason for this is that real-time operating systems are not meant for general purpose applications and, therefore, don't burden the system with a bunch of extra code that is not needed in an embedded device. The burden of extra, non-optimized code is apparent when one compares a tuned embedded OS with a general purpose OS that has been shoe-horned into an embedded device. Additionally, truly embedded operating systems will take advantage of hardware acceleration in order to deliver good response times while keeping energy consumption at a minimum.

Sluggish behavior is also due to poor OS handling of interrupts. Handling interrupts is particularly important in embedded systems. The OS must be able at any time to quickly respond to an event, take the correct course of action, and return control to the proper application. Any inefficiencies that are introduced by the OS and its handling of interrupts usually manifest at the worst time. This occurs when the user is trying to utilize the full capabilities of the device and when the device is at peak load.


Another attribute of network-based communications is security. Quite often, while browsing the Internet, servers will require secure communications. This is also important when retrieving email to be viewed on a portable device. Any type of encryption can overload a system. Another technique that real-time embedded operating systems allow is hardware off-loading. Hardware manufacturers provide hardware acceleration to reduce the load on the processor that complex encryption algorithms create; off loading this encryption to hardware is a necessity. This allows the application more processing time while not putting a halt to communications. A full-featured, real-time OS will contain this ability and as a result, will prevent taking precious processing time away from the application.

USB Connectivity

It's no longer a question of whether devices have USB connectivity. The question now is how many different types of devices USB can connect? USB has become the number one connection of choice among the general public because it is easy to use and offers a wide range of communication protocols. The most common usage for USB is uploading and downloading digital media to a device. In some cases, it is used for networking communications, and in other applications it is used to charge the battery of the portable device. Same device, same connection, only different functions.

USB has many different built-in protocols from file storage, document printing, to networking. When a device connects to another device, time is spent determining if the two devices are compatible. The more devices that are supported, the longer this phase can be. A real-time OS provides the ability to turn off the protocols that will not be used and thus, reduce the time needed for the devices to communicate to each other.

Within the USB realm, as with hardware interfacing software, interrupts can be disabled to make sure that tasks don't interfere with each other. This does create a slow down in the system, hampering responsiveness. As mentioned previously, the real-time OS cannot be allowed to disable interrupts randomly. Any disabling of interrupts should be well calculated and performed minimally to retain the real-time nature.

Graphical User Interface

The final component of a full-featured OS is perhaps the most important to the end user — the graphical user interface (GUI). This is where users will spend most of their time either browsing the web, watching videos, playing games, or simply navigating menus. The GUI is where device manufacturers can differentiate themselves through usability and clarity. This is also an area where a system can become bogged down while performing matrix manipulation and transformations on image data.

Like encryption, decoding encoded media formats and rendering them to a display is CPU intensive. This one area is where having an OS that is tuned for embedded, if not all devices, truly pays off. So how is an OS tuned for decoding and rendering graphics? For one thing, it exploits all the hardware it needs to do the job. It provides and utilizes the most efficient codec or, better yet, it provides a software layer that hooks into the hardware. This provides a "hardware codec" that mimics the software, but it does this more efficiently in terms of time and power.

In this case, not only does the OS provide for managing the codec and rendering hardware, but it also isolates the application code so that it is portable from one hardware target to the next. This minimizes the amount of work one has to perform when migrating their application hardware from target to target.


Without question, a full-featured, real-time operating system is required for today's electronic devices. Keeping tabs on what the operating system is doing should not be a burden the application developer must endure. A good OS helps the application in the most mundane of tasks managing hardware and its connections. The OS should not control the application. Additionally, a good OS helps developers and device manufacturers span the gap between "easy to use" and "easy to carry" packages.

By starting with a full-featured, real-time OS, the application developer can be assured that the required features are there to support the requested technology while the system stays responsive, which in the end, is what the end user has come to demand.

This article was written by Todd Brian, Product Manager for the Embedded Systems Division of Mentor Graphics (Wilsonville, OR). For more information, contact Mr. Brian at This email address is being protected from spambots. You need JavaScript enabled to view it..