Open Source Software for Real-Time Solutions
If an application is to run on batteries or any other limited-power environment (solar panels, radio-isotope powered generators, etc.), a host of considerations come into play. The obvious one is that the hardware must be able to run with limited power. In general, the more powerful a processor is, the higher the power consumption. The more overhead imposed by an RTOS, the more powerful the processor must be in order to do its job. That translates into shorter battery life, which translates into annoyed customers and lost sales.
Most battery-powered devices have extreme size and weight constraints. The cell phone makes a good example. If your “full-featured” RTOS has a large ROM or RAM footprint, you will pay for that footprint not only in memory cost, but in battery life as well. Similarly, if your RTOS is not efficient and requires more cycles than another RTOS to do the same job, then even if it meets your real-time constraints, it may still blow your power budget.
Not so obvious are the implications of power failures. For example, if a user has just punched a new phone number into her cell phone and the battery dies, she will be annoyed if the new number wasn't saved. You cannot afford file corruption caused by power failure. This means the designer has a tight window between the time the last digit is pressed and when the data is saved to permanent storage.
Linux, with its lazy writing to non-volatile storage and the multi-user overhead in its file systems, was not deemed acceptable by Cygnus. A battery-powered application requires an RTOS designed from the ground up for speed, efficiency and utter reliability.
One thing that drives almost all real-time projects is time to market (even student projects are driven by time to grades). Cygnus offers two features that will appeal to the embedded processor engineer.
First is ease of configuration. Having learned from the GNU compiler, Cygnus provides compile-time configuration tools that allow the user to select the components to include or exclude. In addition, the components themselves are configurable, and you have full access to the source for each component and can customize it to suit your application.
eCos achieves globally the sort of modularity that Linux achieves with its drivers. Linux was driven to modules by management issues and to minimize interfaces. eCos was driven to greater modularity by the customers' desire for configurability. As it happens, both get portability as a byproduct, and eCos will gain from the decentralized management made possible by its modularity. That decentralization is essential to the success of an open-source product; something RTOS vendors who make it difficult to access their source have missed. (See Linus Torvalds, “The Linux Edge”, also in Open Sources: Voices from the Open Source Revolution, O'Reilly, 1999.)
eCos is currently configured with scripts on Linux and by a GUI program for Microsoft Windows.
Some RTOSes, designed to target the consumer market, do offer the capability of adding an application framework like a Java virtual machine. Again, open source and the bazaar come to the rescue: third-party virtual machines have been ported to eCos, which allow dynamic addition and removal of applications.
The other feature Cygnus offers is its customer support. When time to market is a big factor, fast, expert support is essential and worth the cost. Cygnus' experience supporting gcc will come in handy here.
This is not to say that you must buy Cygnus' support to use eCos. Cygnus offers an e-mail list for eCos users, for which it charges nothing. It also publishes the source on the World Wide Web. If you want to support yourself by looking through the code, you can do that, too.
Koester contends that eCos and RTLinux don't really compete. The market for RTLinux is desktop real-time and other high-end applications where overhead is less of a factor or not a factor at all. The market for Cygnus' eCos is the embedded processor market, where overhead is a major factor.
Both eCos and RTLinux have their places, and, says Koester, can coexist. For many real-time applications, RTLinux is overkill at the expense of power, price, and product performance. eCos can be driven to the higher end of the real-time spectrum, at the cost of losing the standard desktop applications that make RTLinux so attractive.
While very different in the markets they are intended to serve, Linux and eCos are in fact similar in fundamental concept. Each is a monolithic kernel. Both use modularity, and both are portable because both embody some abstraction of the hardware layer.
Ultimately, says Koester, it is consumer requirements which drive RTOS requirements. Consumer requirements are greatly varied, and so there is room for any number of open source RTOSes.
Charles Curley (firstname.lastname@example.org) has worked with computers for twenty years, in real-time embedded projects such as power inverter/battery chargers, theatrical lighting controllers and data collection computers. He has written compilers and operating systems for such applications. He has written embedded projects in assembler, C and Forth, and used 8, 16 and 32-bit processors.
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis