|
|
source code UNIXEmbedding Source Code UNIX in the Product
by Bob Gray
Bob Gray is co-founder of Boulder Labs, a digital video company.
Designing architectures for performance has been his focus ever since
he built an image processor system on UNIX in the late 1970s. He has a
Ph.D. in computer science from the University of Colorado.
Let's consider some of the advantages and disadvantages of using Source Code UNIX as the operating system controlling an embedded product. I'll examine the issues, the choices, and some concrete successes. An "embedded product" has a processor (CPU), some memory, and a controlling program to produce the required features and functionality. Household appliances these days are often embedded products. A typical refrigerator has sensors to monitor the environment, including temperature and humidity. Based on these and the user-settable parameters (user interface), the controlling program gives commands to fans, motors, heaters, and lights to achieve the desired results. Mass-produced embedded products have characteristics and economies of scale that warrant custom software -- possibly cast in stone (or silicon). Usually the software is relatively simple and unchanging. Minimizing the cost of goods, especially the hardware, is extremely important. When you are building a million cars, stereos, or dishwashers, you'll choose to spend $500,000 on a custom ASIC (custom application-specific IC) if it will save a few bucks per unit. The embedded products that this article discusses resemble general-purpose workstations. Medical-imaging systems, laser printers, gateway routers, and vision systems have powerful processors, many megabytes of memory, disks, communications channels, and user interfaces. Often such products require virtual memory and multitasking. For these kinds of systems, the prices and quantities sold have characteristics different from more common and abundant appliances. In most cases, a short development time is more important than a small cost reduction for the hardware. The case for Source Code UNIX is strong for these products. Operating System Features Let's look at the issues involved when choosing software for controlling an embedded system. You'll want to consider how much total development effort you can afford and how long the development can take. Most organizations are eager to get things working in the shortest amount of time using a modest engineering team. Leveraging an existing, appropriate operating system will save costly software-development time. Further, risks are reduced because you start with part of the project already completed. A key phrase in the above paragraph is "appropriate operating system." It wouldn't make sense to use the sophisticated UNIX operating system to control a washing machine. You need to look at your requirements and choose an OS that covers almost all of the needs. But plan for future features and enhancements, because most successful products have follow-on versions that place more demands on the software. For example, maybe the initial version of your product operates in standalone mode. If it is eventually going to be connected to other devices, you should think about an operating system that has network protocol stacks. Similarly, if "release 1.0" has all processes in physical memory, but you can see a requirement to add many more tasks in the future, you might want to start with a virtual-memory, paging system. Here are some questions to ask:
All of the above are large undertakings. Do you have the time and resources to build them yourself? Operating System Choices Let's say that you are the head software engineer responsible for building the product. If you are in from the beginning, you'll have some say in the selection of a processor type, a bus technology, a memory system, and peripherals. For example, MIPS has the largest number of embedded processors in the field -- mostly because of its price/performance advantage over expensive chips such as the Pentium. But choosing this processor has to be balanced with the software-development costs. If you develop on Pentiums, you may need a cross-compiling environment and will sometimes be faced with problems such as endianness. For modest I/O requirements, a PCI bus will suffice; otherwise, you'll need a proprietary design. It's best to stick with mainstream components unless there are compelling reasons to go with specialty items. While considering hardware, look at your software choices and balance everything with cost, development effort, and time to market. Don't forget the cost of testing and maintenance. The main Source Code UNIX systems, Linux and the BSDs, cover the popular processors: Motorola 680X0, Pentium, SPARC, PowerPC, StrongARM, MIPS. The same is true for the commercial realtime operating systems. (I'll use the term RTOS for the commercial embedded operating systems below. Most have hard realtime scheduling priorities.) Your choice between Source Code UNIX and an RTOS will boil down to what features are provided and at what cost. Rarely is source code available for an RTOS at a modest price. Often, you'll have up-front costs and per-unit costs to use RTOS binaries in your product. The primary reason to consider Source Code UNIX is self-directed control of software development. You can examine the code to see in detail what is going on and modify it to achieve your objectives. If you are lucky, there will be an RTOS that closely meets your requirements -- it might not require any changes. But if it lacks features or performance crucial to your product, you could be in trouble. The vendor might be willing to make custom changes for you, but that will cost you time and money. Depending on the size and nature of the modifications, your budget or schedule might be broken. In contrast, if you have source code, you always have the option of making enhancements yourself. If the system is misbehaving, you can track down the problem with your own resources instead of waiting for the vendor to get to it. A unified environment for development and the embedded system enhances productivity. Any time you can carry out a large portion of software development and testing on your workstation, you improve the development cycle. The value of familiar compilers and tools should not be underestimated. While waiting for your hardware engineers to build your custom components, you may be able to simulate the equipment on a general-purpose workstation. Examples of Embedded-Systems Projects A Video-Recorder ProductIn late 1995, as head of software in a tiny startup company, I had the job of designing and implementing the software to run a disk-based, high-end, video-recorder product. The combined audio/video data rate required storing or retrieving at about 30MB/second. Commodity disks of the day could only sustain a rate of about 5MB/second. Clearly we had to stripe the data across multiple disks. We also required redundancy against a single disk failure and achieved it with RAID3. We homed in on the mainstream technology of SCSI disks, PCI buses, and Intel Pentiums. The naive hardware guys thought that NT would be the ideal software to run our product, but they had been brainwashed by a large corporate marketing organization, and they really didn't understand the issues. Given that we were going to build our own video card and motherboard (containing 20 SCSI buses, 3 PCI buses, Ethernet, and a high-bandwidth memory system with its own XOR engine), I saw that we needed source code to achieve our ambitious goals. The complexity of the product required a multitasking, virtual-memory, demand-paged operating system. We needed network protocols, a graphical user interface, and control over process scheduling. I knew we would require many enhancements in the SCSI subsystem for error recovery and hot swapability. Source Code UNIX was a great fit for the problem. Linux was a candidate, but I ended up choosing FreeBSD because of the better SCSI-driver support and because I had experience with BSD UNIX dating back to the late 1970s. We leveraged many parts of FreeBSD source-code UNIX -- many of which are not available in an RTOS. We had to get into the kernel to tweak PCI-bridge code, customize the serial driver, and make a handful of changes to boot-up code. We put much effort into improving the SCSI driver for our RAID system -- the generic improvements were given back to the UNIX community. Our GUI leveraged X11 and Tcl/Tk. The product can be remotely upgraded with CVSUP (a software package for distributing and updating source trees from a master CVS repository: see <http://www.freebsd.org/handbook>). Think of this as an elaborate EEPROM upgrade, such as you would do for a flashable modem. We came up with a clever file-conversion mechanism using a lazy evaluation mechanism that leverages the UNIX vnode infrastructure. By accessing virtual files in the name space, implicit color-space conversions and file wrappers are invoked. See the code in BSD kernels under sys/miscfs for examples. We served network files to UNIX, Macs, and PCs using NFS and Samba. We wrote numerous custom drivers for our hardware (temperature sensors, XOR engine, LED displays, etc.). We had existing drivers as reference guides, so extending the code to match, for example, the DEC 21143 Ethernet chip was easy. We built the hardware and software from scratch with a team of 10 in 14 months. I can't imagine completing such a project in a reasonable amount of time without source code. A Laser-Printer ProductA few of us are currently improving the performance of a medium-priced laser printer. It needs a full-featured operating system to support tasks like interpreting and printing PostScript, PCL, and rendering images, graphics, and other material. Printers have disks for spooling, fonts, and paging. Interfaces to the printer include serial and parallel communications and Ethernet. The printer can receive jobs via FTP or spooling mechanisms, or just by sending the bits. Status and control are available using Telnet or HTTP Web interfaces. Printers of the current generation have huge virtual-memory needs. An 8.5 x 11 image with vertical resolution of 1200 dpi and horizontal resolution of 2400 dpi has about 256 mega pixels. Using a byte for each of cyan, magenta, yellow, and black planes (CMYK) requires 1GB to hold an image. Then multiply that by double-sided, multiple-copy, and n-up printing. Don't forget that page rasters have to be retained in case of an error such as a page jam. I think you can see that printers have more to their operating systems than it may first appear. We're using an older Source Code UNIX--like system now, but plan to move the next generation MIPS R5000 product to an OpenBSD base. I'd like to point out that one of the remaining inefficiencies of the printer product is TCP throughput. This is one of the few pieces for which we do not have source code. The associated vendor is not very interested in improving his microcode. An Image-Processing System
In the late 1970s, we were awarded a contract to build an
image-processing system for the Defense Mapping Agency. It would
include a flatbed scanner, stereoscopic, high- As a part of the image-processing system, we had a high-speed A/D converter connected to a PDP-11. The general belief was that even though UNIX had all of the right auxiliary processing tools for the collected A/D data, we would need a "realtime" kernel to interface to the device. We had to spend only a couple of days to write a device driver that sampled the data at interrupt time and buffered it. Ten lines of UNIX code were changed. No samples were lost, and UNIX happily ran on the same computer. Other Commercial Products Using Embedded Source Code UNIXCobalt Networks Qube 2 is a low-cost server appliance that provides Internet connectivity, email, Web publishing, and other Web and network file services. Running Linux on a 250MHz MIPS, it allows developers to add Web-server-based applications. See <http://www.cobaltmicro.com>. The Whistle InterJet, using FreeBSD, provides email, Web access, and Web publishing for a small office. Whistle has been an active partner with the Open Source community, using and contributing to the Open Source projects. See <http://www.whistle.com>. When Not to Use UNIX Some RTOS vendors have extremely good products. Their code might fit your problem like a glove. If your problem matches the features of an existing RTOS but doesn't fit the UNIX model, your choice is easy. Remember, many of the commercial vendors have a long history of serving particular areas in the market. Their mature product could be what you should use. At first, I was going to recommend against UNIX for the small, nonpaged systems, but a Source Code UNIX can be stripped down to fit many situations. PicoBSD demonstrates that there are advantages for using UNIX even in tiny environments; it is a one-floppy version of FreeBSD, which in its different variations allows you to have secure dialup access, a small diskless router, or even a dial-in server. And all this on only one standard 1.44MB floppy. It runs on a minimum 386SX CPU with 8MB of RAM (no HDD required!). See <http://www.freebsd.org/~picobsd/picobsd.html>. Also see Linux tiny projects, below. I would say that UNIX is a waste if you have only a single process. If you have no resources to control, you don't need an operating system, but as soon as you want to have multitasking and process scheduling, the advantages begin accumulating. Conclusion Building good software in an embedded product is hard. For some applications, a commercial RTOS will fit the problem, but there are a large set of applications where a binary-only operating system will get in the way. Developers who have had UNIX source code know the tradeoffs. Programmers who have never had access to an open-source operating system might not appreciate the advantages. Peter Neumann[1] sums it up nicely: "The potential benefits of robust open-source software are worthy of considerable collaborative effort." Give it a try. Reference [1] Peter G. Neumann, "Robust Open-Source Software," Communications of the ACM, February 1999, Vol. 42, No. 2. See also <http://www.opensource.org> and <http://www.gnu.org>. Resources for Source Code Unix You may feel that some consulting help or commercial support would best fit your needs. You have a number of options, including hiring consultants such as those found at: <http://www.freebsd.org/commercial/consulting_bycat.html> <http://www.openbsd.org/support.html> <http://www.linux.org/business/index.html> <http://metalab.unc.edu/LDP/HOWTO/Consultants-HOWTO.html> You could turn to companies that specialize in embedded Source Code UNIX: Cygnus is a leader in Open Source--based software development tools, mission-critical support, and custom engineering for the embedded-systems market. <http://www.cygnus.com>
Boulder Labs specializes in high-bandwidth embedded UNIX systems. RTMX O/S is based on OpenBSD; they add realtime scheduling, high-resolution timers, and contiguous file support. Complete source code for the RTMX O/S extensions and drivers is available. They support a large set of processors including those listed at <http://www.rtmx.com>.
Linux/Microcontroller project: <http://ryeham.ee.ryerson.ca/uClinux muLinux> Resources For Commercial RTOSpSOSystem has realtime multitasking kernel and networking support for a large set of processors. <http://www.isi.com/Products/pSOS/index.html> VxWorks, from Wind River Systems, is a realtime operating system with networking facilities. <http://www.wrs.com/products/html/vxworks.html> Inferno is designed to be a complete solution for the embedded market, uniting operating-system functionality, networking, and security within a small-footprint OS platform. <http://www.lucent.com/inferno> BeOS was designed as an operating system for processor-intensive multimedia and Internet applications. <http://www.be.com> LynxOS is a scalable realtime operating system with UNIX/POSIX APIs. LynxOS looks and feels like UNIX but was developed with deterministic hard realtime response in mind. <http://www.lynx.com> QNX is a realtime, extensible POSIX OS with a lean microkernel and a team of optional cooperating processes. This flexible architecture lets you scale QNX down for lean embedded systems or scale it out to create a virtual supercomputer orchestrating hundreds of processors. <http://www.qnx.com> Thanks to reviewers Mike Durian, Jeff Haemer, and Tom Poindexter.
|
 Need help? Use our Contacts page.
First posted: 15 Apr. 1999 jr Last changed: 15 Apr. 1999 jr |
|
Issue index