Watching the season premiere of “Mad Men” last week got me thinking about hair styles and those skinny neckties of the early ’60s. Exactly what is fashionable? Ask that question today among embedded software developers, and you’re bound to get a simple, straightforward answer: Android. And while Android rightly deserves much of the attention, it’s not the “be-all, end-all” of operating systems in use today.

No doubt there’s been a lot of noise and enthusiasm for Linux and Android. In fact, many developers viewed the rise of Linux as some kind of cage match: Linux versus all other commercial OS’s. Over time, and with the accumulation of real-life experience and a few jabs of reality, we can clearly state that there is no winner, as each OS has its own strengths and weaknesses.

When it comes to deciding whether to use a general-purpose OS such as Linux or real-time OS (RTOS), you needn’t look any further than the application you’re planning to build. There are both technical and commercial factors to consider.

One technical factor is memory. All embedded systems have some kind of memory limitation. Because memory is now relatively cheap, this constraint may not present too much of a problem. However, there are applications where keeping the memory usage to a minimum is essential; this is particularly true with handheld devices. For these memory-constrained applications, it’s clearly desirable to minimize the OS footprint. This can be achieved through OS scalability. Today’s most popular RTOS’s are scalable, meaning only the OS facilities (i.e. API call service code) that are actually used by the application are included as part of the memory image. Linux, on the other hand, doesn’t enjoy such scalability freedom, but, depending on your application, OS scalability may not be that big of a deal anyway.

Another technical factor is performance, which can be broken down into three key areas: application-code efficiency, CPU power, and OS efficiency. Given that the application-code performance is fixed, a more efficient OS might enable a lower-power CPU to be used (which reduces power consumption and cost) or may allow the clock speed of the existing CPU to be reduced (which can drastically reduce power consumption). OS performance is critical if every last ounce of performance has to be extracted from a given hardware design.

The primary commercial factor is cost. Although selecting an OS is theoretically a technical endeavor, financial issues can strongly influence your choice. There are initial costs, which may include licensing the software or procuring the tools, and there are ongoing costs, which might include runtime licenses or maintenance charges. Further, time-to-market should also be figured into cost. Time-to-market may be very tight for a state-of-the-art device, so the extent to which the choice of OS can accelerate development may be measured as a cost or, rather, as a saving. There is also the question of ongoing support: who will provide it and for how long?  

It’s obvious that both Linux and a commercial RTOS each have their place, depending upon the characteristics of the final application. An RTOS makes fewer demands upon resources and is a good choice if memory is limited, real-time response is essential, and/or power consumption must be minimized. Linux or Android makes good sense when the system is less constrained and full advantage of the huge range of available software components (drivers, application code etc.) can be leveraged.

A while back, a Mentor Graphics customer, BitRouter of San Diego, found itself going through this OS selection process. What follows is a brief interview with BitRouter’s founder and president, Gopal Miglani, and its VP of engineering, Paul Freeman. The two gentlemen were willing to share their insights on balancing the advantages and disadvantages of a commercial RTOS against embedded Linux.  

CW: To begin, can you provide a description of the type of systems you build at BitRouter?

GM: We build software components and turnkey software solutions for set-top box and television applications. We primarily target set-top box and TV solutions for the North American market. Our software runs on six operating systems, six processor cores, and SoCs from 16 different silicon vendors.

CW: You’ve had experience using embedded Linux?

PF: Yes, we’ve implemented systems using Linux, Nucleus, uC/OS-II, VxWorks, OS20 and Win32. Linux works great. We’ve used commercial Linux as well as embedded Debian Linux for ARM ourselves. In general, Linux tends to use much more ROM and RAM than does a traditional RTOS. It also increases total boot time from around three seconds to ten seconds.

CW: And the commercial RTOS?

PF: We’ve used the Mentor RTOS [Nucleus] in three major set-top box projects. In general, we’ve always selected Nucleus for small footprint, modest functionality and high-volume set-top box applications.

CW:  Perhaps you could explain your decision to look at an alternative for a particular project?

PF: A few things we like about Nucleus are its compact code, which equates to cost savings in flash and RAM, [and] the availability of the source code. We liked the royalty-free license model, and Mentor’s flexibility when we needed to reuse licenses for multiple customers. Mentor support was also extremely important.

When we compared this with Linux, we saw an end product with a larger flash and RAM footprint. We call this the “Linux royalty.” If you have to go from a 2MB flash part to a 4MB part or from a 16MB RAM footprint to 32MB RAM footprint, that adds real cost to the end product.

CW: Going forward, what’s your embedded OS strategy?

GM: We feel that Nucleus is more suited for small, compact and high-volume systems where memory footprint and boot-up time are an issue. Linux tends to shine when multi-process support is needed. One great benefit of Linux is the sheer volume of open-source software available. We think that Linux will be a good fit for Java-based set-top box and TV sets where the total RAM footprint exceeds 64MB. Once a device supports a disk drive, it doesn’t require flash memory. This reduces some of the cost advantage Nucleus has over Linux. We see a continued need for both kinds of operating systems. We plan to continue developing our software stacks in a manner that can port easily between multiple operating systems.

About the author: Colin Walls has over 25 years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is a member of the marketing team of the Mentor Graphics Embedded Systems Division and is based in the U.K. His regular blog is located at: http://blogs.mentor.com/colinwalls. He may be contacted at colin_walls@mentor.com.