feature article
Subscribe Now

Linux or Commercial OS?

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.

 

Leave a Reply

featured blogs
Nov 25, 2020
It constantly amazes me how there are always multiple ways of doing things. The problem is that sometimes it'€™s hard to decide which option is best....
Nov 25, 2020
[From the last episode: We looked at what it takes to generate data that can be used to train machine-learning .] We take a break from learning how IoT technology works for one of our occasional posts on how IoT technology is used. In this case, we look at trucking fleet mana...
Nov 25, 2020
It might seem simple, but database units and accuracy directly relate to the artwork generated, and it is possible to misunderstand the artwork format as it relates to the board setup. Thirty years... [[ Click on the title to access the full blog on the Cadence Community sit...
Nov 23, 2020
Readers of the Samtec blog know we are always talking about next-gen speed. Current channels rates are running at 56 Gbps PAM4. However, system designers are starting to look at 112 Gbps PAM4 data rates. Intuition would say that bleeding edge data rates like 112 Gbps PAM4 onl...

Featured video

Synopsys and Intel Full System PCIe 5.0 Interoperability Success

Sponsored by Synopsys

This video demonstrates industry's first successful system-level PCI Express (PCIe) 5.0 interoperability between the Synopsys DesignWare Controller and PHY IP for PCIe 5.0 and Intel Xeon Scalable processor (codename Sapphire Rapids). The ecosystem can use the companies' proven solutions to accelerate development of their PCIe 5.0-based products in high-performance computing and AI applications.

More information about DesignWare IP Solutions for PCI Express

Featured paper

Top 9 design questions about digital isolators

Sponsored by Texas Instruments

Looking for more information about digital isolators? We’re here to help. Based on TI E2E™ support forum feedback, we compiled a list of the most frequently asked questions about digital isolator design challenges. This article covers questions such as, “What is the logic state of a digital isolator with no input signal?”, and “Can you leave unused channel pins on a digital isolator floating?”

Click here to download the whitepaper

Featured Chalk Talk

Benefits of FPGAs & eFPGA IP in Futureproofing Compute Acceleration

Sponsored by Achronix

In the quest to accelerate and optimize today’s computing challenges such as AI inference, our system designs have to be flexible above all else. At the confluence of speed and flexibility are today’s new FPGAs and e-FPGA IP. In this episode of Chalk Talk, Amelia Dalton chats with Mike Fitton from Achronix about how to design systems to be both fast and future-proof using FPGA and e-FPGA technology.

Click here for more information about the Achronix Speedster7 FPGAs