Open Source Software for Real-Time Solutions
Much hype is circulating in the industry today about open-source software and Linux. These discussions have focused on how Linux represents the first major threat to Microsoft's domination of the desktop. However, open-source software is also moving into the embedded real-time marketplace. Last year, Cygnus Solutions unveiled a new initiative called eCos (embedded Cygnus operating system). eCos is available as both open source and royalty free. Today, eCos has been downloaded by well over 10,000 developers. Why didn't Cygnus choose Linux as its open-source real-time alternative? This article will compare and contrast these two alternatives and explain why each can have a place in your real-time solution.
To see why Cygnus developed its own real-time operating system (RTOS), you must look at what is on the market and the type of job Cygnus wanted to take on with its RTOS.
Cygnus was founded in 1989, effectively pioneering the open source business model. While Linux is the poster child for open source today, Linus Torvalds was in fact inspired by earlier open-source projects, especially the GNU C compiler (gcc). The Free Software Foundation's (FSF) Richard Stallman first released the GNU C compiler in mid-1987, and Michael Tiemann, then a research scientist, quickly adopted it. Tiemann's contributions to the GNU C compiler, which included ports to several RISC and CISC microprocessors, a complete native-code C++ front-end, and optimization passes for instruction scheduling and branch scheduling, created more demand for code development and support than he (or any of the other gcc hackers) could provide in their spare time. Tiemann decided that this demand was not a fluke, but a result of deeply seated economic principles, and founded Cygnus to prove it. (See Michael Tiemann, “Future of Cygnus Solutions” in Open Sources: Voices from the Open Source Revolution, O'Reilly, 1999.)
Cygnus was in the real-time business almost from the beginning. When the GNU C compiler acquired a reputation for runtime speed and compact code, it came to the attention of real-time developers. Exercising the freedoms uniquely available from the open-source bazaar, these savvy developers asked for, and contributed back, further enhancements to the compiler, making it an even better choice. Cygnus, their customers and the Net community were seeing the power of the bazaar in action.
Early on, Cygnus identified configuration tools as one of the key technologies for making it possible to support many microprocessors from a single source base. They created the “configure” script (one half of the famous “configure; make” process for building FSF and Linux applications and utilities), opening the doors to a true multiplatform solution. Many companies that depend on embedded processor projects move rapidly from processor to processor to gain new capabilities or to get the same capabilities in a smaller package. As a result, the GNU C compiler supports some 50 processors today, and 125 host-target combinations are available for cross compilation. In two years, Cygnus may see a 90% rollover in the processors it will support with gcc. They may write 24 new processor ports in a year, a tremendous output for a company that doesn't even own the product it is supporting.
Meanwhile, Cygnus assiduously sought out its customers' wants and wish lists. They had to understand why they were getting—or losing—sales. By 1995, they knew their customers needed standardized runtime support that integrated completely with the GNU gcc compiler, gdb debugger and tools on the host. The runtime support needed to include a C library, hardware abstraction layer (HAL), debugger support and a wide range of RTOS functionality. As with gcc, portability was a key ingredient, as it had to be available for a wide range of architectures and evaluation boards.
In moving into the RTOS business, Cygnus had to consider its own strengths and weaknesses. To judge by the plethora of proprietary closed-source RTOSs (over 120 in 1995), anyone can make a buck with a proprietary RTOS. At least, that's what many people would like to think. Actually, an RTOS, like a restaurant, is a truly good way to go broke fast, unless you know exactly what you are doing.
What Cygnus needed was an open-source RTOS. Many products actually come quite close. Typically, the user has access to the source but the vendor owns it, and you don't see the source until after you buy the product. Part of the purchase is a non-disclosure agreement, which prevents you from trading improvements with other users of the same product. These constraints are anathema to the open-source model.
A number of Linux variants offer real-time capabilities, all of which are open source. Probably the best-known is Victor Yodaiken's RTLinux. More are listed at the Linux Embedded web site. Any RTOS must be highly configurable, because embedded projects run on very different hardware, almost always custom hardware. If you think PCs vary greatly, you haven't looked at embedded projects.
To give an example, Linux might support an infinite number of some resource—say, mutexes or timers—or it might supply a fixed but very large number of them. It must provide that flexibility, because the designers have no idea which applications the user will run. That flexibility has a cost: the resources, such as memory, to support it, or the code to spawn a new one. An embedded project designer knows exactly how many of something the project will need, so he can select that number before compiling. The embedded project trades runtime flexibility for compile-time flexibility and gains simplicity and reliability. Thus, in addition to open source, Cygnus needed an easily configured RTOS.
Offering real-time capabilities isn't the same as offering a full-blown RTOS. To see why, let's look at real-time programming and projects.