Real-time operating systems and kernels provide all the functions you need for a multitasking embedded system . . . and then some. It may make more sense than you think to embed do-it-yourself operating system functions into your application.
The following article first appeared in February 1989 issue of Embedded Systems Programming magazine.
If you read the multitude of articles on the subject, you might think the only way to design a PROM-based system is to use a commercial embedded operating system or real-time kernel like PDOS, VRTX, or OS/9. But there is an alternative, one that's quietly being used by a significant number of designers, and that is simply to write fully stand-alone software. Let's compare the two approaches based on two criteria--ease of use and versatility.
In comparing ease of use, we're faced with two options; unfortunately, each requires us to learn an interface. If we choose to write stand-alone software, we must learn the workings of various hardware components, among them serial, timer, and interrupt chips. These complicated chips often require extensive study before they can be accessed in a standalone environment. Buying a real-time kernel also challenges the designer to learn a fairly complicated interface and, in many cases, still requires the applications programmer to learn the details of the hardware components being accessed.
Besides the hardware issues, we must consider some purely software structures. The real-time kernel provides multitasking, a facility that would have to be created from scratch in a stand-alone environment. Here the real-time kernel seems to have the edge in ease of use, though there are (as we shall see) competitive alternatives in this area as well.
In a comparison of versatility, obviously nothing can beat the stand-alone environment. Real-time kernels are versatile enough for a wide range of applications, so the question is whether the versatility provided by the real-time kernel is sufficiently close to the absolute versatility of the stand-alone environment for your particular application. The commercially available real-time kernels are the result of many hours of development; an attempt to duplicate the functionality of one of these little gems would require a larger programming effort than would be justified by any single project. But programmers who write stand-alone software don't duplicate that functionality, because they simply don't need all of it.
Power-up initialization
A real-time kernel or operating system normally takes care of power-up initialization. For the 68000 family, this involves setting up RAM vectors, a stack pointer, and the interrupt level. For the 8086 family, segment registers must also be initialized. A sample initialization routine is provided with most compilers designed for stand-alone use, so this feature isn't hard to provide. Beyond processor initialization, major hardware components such as serial ports, timer control delays, and interrupt chips must be initialized.
The first and most basic function of a real-time kernel is to provide access to the hardware. A typical CPU beard in a VME-bus or STD-bus system has a serial port that may be connected to an operator's console. If the application software is being written in C, you may want to have the getchar() and putchar() functions defined for you. This is all you need for your first "Hello, world" program.
While it's true that using the real-time kernel for this access may be easier than writing your own driver, it's also true that the initialization, input, and output drivers for a serial chip often take fewer than 50 lines of assembly code. In many cases, that code is supplied by the board manufacturer. If your application calls for an interrupt-driven serial input and output facility, the simple interface offered by the real-time kernel will rarely suffice.
In a project I was involved in recently, we connected a number of single-board computers by their serial ports to a multidrop serial bus. A proprietary addressing protocol was used to target listeners on the bus. By writing our own driver, we were able to implement the addressing state machine within the serial input interrupt service routine. Characters following the addressing sequence were buffered by the addressed board and discarded by all the other boards. Doing all this below the level of getchar() meant that the application code could be written independently of multidrop communication. It would have been difficult to implement this interrupt-driven selective response using the typical canned serial input driver.
