Not too many years ago, finding a resident operating system in an embedded system was atypical. Very high-end embedded systems might have had something like QNX as resident. Things have changed very quickly in this genre, and as devices get smarter and smarter, embedded Linux development appears to be the area with the most intriguing upside.
Continual development has brought the proliferation of somewhat more general-purpose and flexible embedded systems such as cell phones, TV set-top boxes, and personal digital assistants. With the low price and small footprint of today’s memory chips and highly functional microcontrollers, it is now quite common to find an OS in such low-cost, consumer-oriented devices.
Of course, there remain a large number of embedded systems that do not need a resident OS. In addition, there are devices in a gray area that may not have a resident OS but might profit from the addition.
Advantages of using a resident operating system
An OS offers various advantages:
- since an OS typically has a rich set of well-tested primitives, they can be combined to provide desired functionality without requiring reinventing (and debugging) the wheel
- after its initial deployment, the OS provides a familiar path for enhancing and otherwise modifying the product
- the OS has built-in capabilities for a wide range of purposes e.g. wireless Internet connectivity, a GUI for the user, and so on
- as a product line matures and evolves, a fully featured, non-stagnant OS will continue to provide what is needed
- training new hires to use the OS is somewhat cut and dried
Advantages when the embedded OS is Linux
Linux inherits the previous advantages of any OS used for embedded development. However, it offers some additional advantages, which we’ll discuss here.
For starters, there is a large and helpful development community. As a beginner, you can find help from the community; as an experienced developer, you can have the satisfaction of contributing back to the community. The community may, in some cases, constitute a valuable set of business contacts; e.g., providing possible contract employees for your company’s projects or providing consulting opportunities for you.
It is well known how Linux has benefited from the pre-existing body of GNU software, and that is particularly true here. Linux is available for a variety of architectures, because the GNU compiler collection (gcc) has been ported to these architectures. As a result, in scoping a new product, you have a rich set of architectures from which to choose. Further, if there is a strong reason to go to an as-yet-unsupported architecture, there is extensive documentation available on how to do the port. And you still have the Linux developer community as a resource.
We are just starting to see vendors who will provide an integrated tool set for developing embedded systems with Linux; Monte Vista and Metrowerks come to mind as examples. On the other hand, you can roll your own and use something like Emacs to concoct a powerful IDE. The tools typically are rooted in GNU software packages, which predate Linux and already have a history in embedded development. The GNU debugger, gdb, is a good example.
Debugging in Linux a big advantage
The subject of debugging is of particular interest. Here, the open-source nature of Linux offers a special benefit. Let’s say you are immersed in debugging an embryonic new product and are struggling with a particularly pernicious bug, and you can’t find anything wrong with your software. It dawns on you that the flaw may be in the infrastructure, drawn from the underlying OS. Because the source is open, you can continue the debugging by crossing into the OS itself. If you find a bug in the OS you can, in one way or another, exterminate it–thereby benefiting yourself and the entire community. If the architecture is a popular one, other developers who encounter OS bugs will also improve the Linux port. The OS will improve, and you will be aware of the details because of communication among the developers. It is difficult for a vendor of a proprietary OS to compete with this model of evolution toward excellence.
Once your embedded system is ready to go to production, you need not pay a per-unit cost for the OS itself. Keep in mind that it is likely that the retraining cost for switching to Linux will be significant. Nevertheless, once the expertise is assimilated, that initial cost can be rapidly amortized. In the long run, the use of Linux is most likely to be extremely cost effective. There are some studies available to investigate this claim, but definitive results will only appear with time. Further, studies sponsored by parties with vested interests are difficult to take seriously.
Who can develop these systems?
Historically it has required significant hardware familiarity to develop embedded systems. This has been subtly but significantly altered with today’s situation, where many embedded projects involve a target with a resident OS. In such an environment, the traditional desktop development tools (e.g. a full complement of high-level languages) can be applied to a wide range of embedded projects. Although it is still true that someone involved in the project must be intimately cognizant of the hardware, other programmers can now be productive. If the embedded Linux marketplace grows as expected, we should note that there already exists a large pool of talented programmers whose skills could be used.
Many of these programmers have had no exposure to embedded systems development but could make the transition with rather minimal retraining. Some of these programmers came out of computer-science programs, rather than the less-common computer engineering programs. The latter students will likely have some embedded systems exposure, whereas the former group is less likely to have had similar training.
How to prepare
Let’s say you are an accomplished programmer but have no experience in embedded systems. How can you begin to make the transition into this new area? Certainly you can undertake self-education. Various books are available.
Here are two recent releases:
Building Embedded Linux Systems, Karim Yaghmour, O’Reilly (2003).
Linux for Embedded and Real-time Applications, Doug Abbott, Newnes/Elsevier (2003).
The first book, by Yaghmour, is a readable yet definitive book and should belong in your self-education library. It may become the classic reference on embedded Linux systems. The second volume is quite different in flavor. While Yaghmour comes across as a generalist, Abbott gives us a very hands-on book and chooses a specific hardware target–an old 486 PC. This book is a good example of the hands-on genre. Coming at the subject from these two viewpoints is a great way to learn.
Computer science departments undoubtedly will be adding embedded systems courses. Typical computer science departments already have curricula employing Linux systems, so the move to embedded Linux courses could be relatively easy. There is something of a problem for schools whose students have very restricted budgets. My university serves that sort of demographic, by and large. The cost to the student for such a course involves two expenditures: a book, and an embedded target.
Where a computer engineering curriculum might have the students build the embedded target, the already busy, crowded computer science curriculum might prefer to use a preexisting embedded target. My approach was to seek and obtain a small grant to support the purchase an appropriate number of embedded target systems.
This will to minimize the cost to the student. For the target, I chose the Sharp Zaurus SL5500, a PDA. The attached workstation is, as you might guess, a familiar Linux box. The next generation of Zaurus products have been brought to market, so the SL5500 is heavily discounted. But even a slightly obsolete PDA makes a wonderful and mobile embedded system target. Many of the capabilities of the Linux OS can be deployed on this PDA.
The intent of the course is to have it grow dynamically by having interested members of the Linux community contribute to enhancing the course (e.g., other target choices). The course is meant for existing programmers who merely need a hands-on introduction to programming in the cross-platform environment typical of embedded systems development. The current beta version of the course can be found at this site.
This may or may not be its long-term home, depending on traffic and security concerns that may arise.
It would be ideal if we could find a target for about $100, perhaps using one of the reference designs that have surfaced in this last year. Then the budget-crunched computer science departments could require the students to purchase the target; the cost would be in line with a book from the textbook market. Where could we find a $100 target that might survive for a reasonable lifetime in the PDA market?
Companies such as IBM and Motorola, which have released reference designs, might consider this as a way to promulgate their design ideas to the next generation of embedded-system programmers. Or perhaps a company like Sharp might consider giving one of its somewhat obsolete PDAs a second lease on life by aiming it at this market. The PDA could be packaged with the free course on a CD. We might also hope that the costs for such products will decrease dramatically as they become commodities.
