Embedded.com Guest Editorial
Embedded OS trends points to Linux...sometimes
John A. Carbone, Express Logic Inc.
12/11/2007 3:16 PM EST
The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.
While Linux and complex RTOS products offer such attractive capabilities, they're also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.
Linux's complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.
But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system's technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There's little time to sort out configuration complexities, or to learn which of the many services are actually needed.
While Linux and complex RTOSs with similar features deliver abundant capabilities, they also occupy a fair bit of memory. If available memory is limited by physical footprint, cost, or power consumption constraints, or if low overhead and a rapid real-time response are needed, then it may be time to take an alternate approach. In such circumstances, a large Linux image or a complex RTOS might not cut it. What might be better is a smaller, simpler, more efficient solution, one that still meets the needs of the application, but doesn't impose unnecessary complexity on top. For such needs, a small-footprint, low-overhead, simpler RTOS might very well be more suitable.
One of the newer trends in embedded software involves designing simpler solutions for applications that don't need all the features. This concept applies to many embedded systems as they may not require virtual memory or hundreds of system services. Instead, many embedded real-time applications need just a few basic capabilities, such as priority-based preemptive scheduling, dynamic memory allocation and recovery, inter-task message passing, interrupt management, resource-locking semaphores, and timers.
Addressing these basic needs enables a simple RTOS to satisfy a large number of applications in consumer electronics, medical devices, industrial automation, test and measurement equipment, and wireless networking devices. Developers of these systems can minimize development time by choosing an RTOS that addresses their needs without excess complexity. Shortening development time pays additional dividends in lower development costs, faster time to market, and greater market share. For these applications, "less" actually is better, and delivers "more" for the developer.
|
|
|
|
|
SPLatMan
12/13/2007 1:09 AM EST
"One of the newer trends in embedded software involves designing simpler solutions for applications that don't need all the features."
Gee golly, what a novel idea. Only thing is, I was doing just that 35 years ago when 2K was a huge footprint, let alone 2M.
Sign in to Reply
vapats
12/13/2007 6:21 AM EST
Often, a commercial OS/RTOS is completely un-necessary; many benefits result from implementing an exactly tuned set of essential services from scratch. Validating code (and documentation!) is much easier when it is written in-house, and version-itis is easier to control.
I can think of numerous examples where probing and diagnosing crucial errata (often in silicon) has been an absolute nightmare under a complex OS (even with a supposedly simplified kernel), contraverting it's mission-statement from being a facilitator, to antagonist.
A good, clean, *up*front* state-machine design for the firmware is essential; relying on an OS to sweep any mess under the carpet is a bad idea, and will bite you in the rear end, every time.
Programmers who are not intimately familiar with the CPU and it's assembler should not be hired; this ain't no cozy little desktop app'.
Even when malfunctions in embedded systems do not result in injury or death, a reputation for bugginess and poor quality will not make you any money...
Sign in to Reply
KWP
12/13/2007 1:24 PM EST
Mr. Carbone could not possibly have an "ax to grind" could he? After all, he hails from Express Logic, which sells the "Thread-X" RTOS...
I have seen over a dozen surveys that show the exact opposite of the one cited in this article-- where the use of Linux is on the rise in embedded devices, and (especially) in small hand-held devices that must display rich-content from the Internet.
Linux as applied to Embedded systems has a steep learning curve. Once you are past that, it is smooth sailing. But, it has it's place. Personally, I like OpenBSD, because of it's focus on correctness and security. OpenBSD will only run (at this time) on machines that have an MMU, so it will not fit well on certain desirable platforms. There is a place for assembly, for C, for a FORTH-based system, for a "home grown" RTOS, for a commercial RTOS, for a free RTOS, and of course for Linux (and it's *BSD sisters and brothers). Remember the old saying: "If all you have is a hammer, then every problem looks like a nail". One should not fall in love with any one technique.
Linux is not for little tiny microcontrollers-- you need at least a 32-bit machine with at least 10's of megabytes of memory. (However, the trend in microcontrollers is to migrate to 32-bits and memory is becoming very inexpensive). Linux is great if what you want is a standard (and open) platform with extensive networking support, and lots of already written and ready-to-go standard applications. That is why Linux is becoming very popular on upscale cellular phones and hand-held PC's. If all you need to do is read a sensor and send a packet somewhere over TCP/IP, there are better solutions, (and not all of them cost a lot of money like the Thread-X RTOS that Mr. Carbone is hawking).
The purpose of an RTOS is to make it easier to break up a large project into smaller, more manageable chunks-- [assuming the almost universally accepted postulate that smaller code snippets are easier to write, debug, read, and understand, and thus are highly likely to contain less errors than larger chunks of code.] The purpose of an O/S is the same, but with a lot of built-in system services as well. It's like talking about apples and oranges-- one is good for a certain domain, and the other is great for another domain-- so I am at a loss why a company hawking an RTOS is attacking Linux, when the two products tend to play in different fields.
Linux is not a "hard" real-time O/S, and perhaps it never will be. BUT-- it *is* getting better, and it now far surpasses anything Microsoft sells in this regard. There are versions of Linux that are built on top of a hard real-time kernel-- and these certainly can and will perform just as well as an RTOS, and at the same time you get all of the fantastic support for networking as well as thousands of applications that are ready to go.
I am not a "Linux FanBoy". That said, I don't think Mr. Carbone was being fair to Linux in his article. As always: "Do your own research".
Sign in to Reply
Anssi
12/14/2007 6:25 AM EST
I just wanted to comment on KWP's claim "Linux is not for little tiny microcontrollers-- you need at least a 32-bit machine with at least 10's of megabytes of memory." A common configuration for Linux-based WLAN boxes is 16 MB RAM and 32-bit processor, but 8 MB RAM is also common. Of course, ucLinux runs on 16-bit processors without MMU too.
Sign in to Reply
paines
12/18/2007 3:50 PM EST
There are several approaches to slenderize the linux kernel. Like Linux Tiny, a number of 40+ patches to do so -> elinux.org
Also, the kernel comes with some options to built it explicitly for embedded systems., printk vanishess etc.
On the other hand you could use a 2.4 Kernel which is smaller by default.
There are several options if you want to use linux.
Sign in to Reply