The PC architecture is continuing its migration to embedded systems. There are many reasons for this migration—as well as some problems this trend has met along the way (Ref 1). But cost still tops the list of forces causing a desktop machine’s conversion to an embedded system.

The price-performance ratio of embed-dable versions of PCs is very attractive. The reduced learning time resulting from using a familiar architecture also tends to lower development cost. You can derive additional savings from the low cost of high-quality tools available in the PC world.

But making a PC work in an embedded environment involves more than just shrinking the hardware. You also need to get your software to run in a system that lacks some of a desktop machine’s key components. Many embedded PCs don’t have a keyboard, a display, or even a disk drive. They also may not have serial interfaces or a parallel printer port. In fact, without the schematics, it may be impossible to tell that it’s a PC.

The embedded PC often runs some version of DOS. Three main players in embedded DOS include Microsoft with MS-DOS ROM, Datalight with ROM-DOS, and General Software with Embedded DOS. Other versions of "embedded" DOS are Microsoft’s MS-DOS, IBM’s PC-DOS, or Novell’s DR-DOS. You can surround these desktop operating systems (OSs) with tools that ease their implementation in embedded systems.

A DOS-based system provides many services for embedded systems. You can opt for whichever services suit your application. The left side of Fig 1 shows a simplified block diagram depicting the layers of DOS. To the right of the dashed line are the applications that use the corresponding PC architecture or DOS layer.

One of the most commonly used services is for DOS simply to load a program and then get out of the way, which is not an unreasonable use of the operating system. Standard PC-based tools used to develop programs assume DOS is present. DOS provides system initialization functions; thus, without DOS, the program must initialize the system on its own.

The file-management system is another DOS service frequently used in embedded systems. If you need a file-management system, you certainly could create your own. But why? The DOS file system is adequate for most needs, and creating a file-management system is deceptively complex.

DOS does not directly supply debugging services, but they are available via DOS; for example, you can use Borland’s turbo debugger in remote mode. Your PC becomes the keyboard, display, and disks for the embedded system. You can debug your code as if the target had this essential human interface.

Other DOS services are useful in embedded systems. Console I/O and keyboard services can provide a simple user interface. Parallel- and serial-port services can help move data around. Embedded systems often need a time-of-day clock (often battery-backed). Memory-management services within DOS can also be beneficial. Beyond the standard services DOS offers, you can add support for networks, special-purpose boards, and graphical user interfaces (GUI).

DOS does have some disadvantages, specifically that it was never intended for use in embedded systems. But don’t underestimate the ingenuity of your peers. It is amazing what DOS has become. One of the biggest obstacles in using DOS in embedded systems is to get it to run without a disk. Running a disk-based OS without a disk requires that the operating system be tricked into thinking that memory is a disk. DOS interprets these solid-state versions of disk drives to be disks. Once the memory assumes the role of a disk, DOS works without change. The memory DOS uses can be RAM, EPROM, or flash ROM, on a board or in a PCMCIA device.

DOS requires memory to run. If your application is severely memory-limited, you may not want valuable resources consumed by something that may provide only a few services.

To drain memory resources even further, a DOS-based system often duplicates your application. It resides on the disk and, when running, resides in RAM. In a diskless system, you need to place your "file" in memory and then have DOS load it into RAM to run. While the application is running, two versions of the application exist. Execute-in-place options exist in versions of DOS intended for embedded use.

DOS is large, but with a few tricks you can make it smaller. For example, if you don’t need the rather large COMMAND.COM file, replace it with your application. Then, when the system boots, instead of loading something you don’t need, it loads just your program.

DOS has always been a single-threaded OS. Therefore, its developers had no reason to create reentrant services. (A reentrant service is one that more than one task can use at the same time.) For example, if one task is using a service when a higher priority task interrupts it, the service remains available to the higher priority task. Once the higher priority task finishes with the service, the service then reenters and completes without data loss. Many embedded systems require reentrant services, and reentrant versions of DOS are available.

DOS-based systems can also work with real-time systems. DOS itself cannot control your system until your application requests a DOS service. For quick-response needs, you can use the interrupts on the X86 processor.

The only ongoing activity in a DOS-based system is the timer tick, which occurs 18 times/sec. But it doesn’t add significant time to interrupt response. Even so, you can disable it because it’s needed only for clock and floppy-disk support. Even if you require floppy services, you can still turn it on when you need to access the disk.

The importance of being compatible with MS- or PC-DOS depends on your application. If you are using DOS only to load an application program or for debugging purposes, then compatibility requirements are somewhat soft. On the other hand, if you wish to add networking services, a GUI, and other services, you may find total compatibility with MS- or PC-DOS a requirement.

Another annoyance for the embedded-system developer is that DOS isn’t deft at handling errors. When an error occurs, a message appears on the console, and the user must respond via the keyboard. This approach can be somewhat of a problem when the embedded system does not have a console or keyboard, or when you don’t want error messages to bother the user.

To work around this, you have to write your own error-handling routines, which isn’t too difficult. To check if everything is OK, you can use the libraries that come with most compilers to query a device before you try to use it.

In many cases, the system can’t get beyond keyboard testing. Most BIOSs will check for the keyboard and, when not found, ask the operator to press a key to continue. Thus, a system without a keyboard hangs forever. A BIOS for embedded use allows you to start the system without a keyboard.

Another drawback of DOS is that it’s rather slow. Using DOS or the BIOS for console I/O, COM-port, and LPT-port operations is not the fastest way to move data. To optimize a system for speed, programmers must use these ports directly. This option takes you to a dangerously low layer by interfacing to the hardware directly. Any change to the hardware requires changes to your application code.

But also realize that, although DOS is slow, the speed of the X86 family of µPs continues to rise. The price of 386 (and above) µPs has decreased to the point that simply getting a faster µP is a real solution to the fact that DOS has not been tuned for maximum performance—and it’s cheaper in the long run than writing your own optimized code.

Many of the problems associated with using DOS in embedded systems have been addressed with DOS versions that suit embedded systems. Microsoft, Datalight, and General Software have versions of DOS that meet a variety of embedded needs.

Microsoft offers MS-DOS in a form that executes from ROM. These versions are available in developer’s kits that include source code for some files so you can customize the OS. Versions 3.22, 3.31, and 5.0 are available in ROM versions. The most popular is Version 5.0, which requires 62 to 115 kbytes of ROM but consumes only about 17 kbytes of RAM.

The ROM versions of MS-DOS are equivalent to the disk-based desktop versions. The ROM versions, however, run out of PROM and treat PROM as a physical drive to eliminate the need for disk drives. The developer’s kit allows you to build a PROM image that you can place in EPROM or flash ROM.

MS-DOS is available from either Annabooks (in low volume) or Micro-

soft (in high volume). Annabooks also sells the MS-DOS Software Developer’s Kit for Version 3.xx for $595 and Version 5.0 for $695. Each kit includes 10 licenses.

Microsoft sells only to large-volume accounts. Version 6.22, fully loaded, costs $28/license (10,000). It costs less

if you don’t need all of the functions. Older versions also cost less.

Datalight’s ROM-DOS is compatible with MS-DOS but, from the start, was developed for embedded PROM-based applications. It can boot from either PROM or disk and takes less memory than MS-DOS. (It also costs less.) ROM-DOS 6 has a 45-kbyte kernel and a 27-kbyte command processor. The minimum system takes up 45 kbytes of PROM and 5 kbytes of RAM. To reduce memory requirements further, ROM-DOS works with a royalty-free mini-BIOS that uses just 3 kbytes. It provides only the BIOS services required by ROM-DOS. ROM-DOS also has a miniature version of the command processor, which takes only 4 kbytes.

Another of ROM-DOS’ memory-saving options is to create RXE files for programs. RXE files are executable files that can run from PROM. Thus, you avoid duplicating the application. But, for most systems, running from PROM is slower than running from RAM. When you build ROM-DOS, you can choose where to run your application.

To use ROM-DOS, your hardware needs to be based on an 80x86 µP and have RAM and PROM. You can configure ROM-DOS to virtually any hardware within these limitations, even if your BIOS is not 100% PC-compatible. Device drivers making BIOS calls handle all hardware communications. Source code that’s also provided lets you modify these drivers to fit your target.

ROM-DOS has been tested with many of the popular DOS applications to verify compatibility. Datalight offers a free demo copy of ROM-DOS so that you can see if it runs with your application.

ROM-DOS is configurable via a build utility; build, a menu-based utility that walks you through the process, automatically configures ROM-DOS for PROM or disk.

ROM-DOS includes a number of utilities, such as remote serial-disk access, which allows a diskless system to access a disk on a desktop machine through a serial port and optional Stacker data compression.

ROM-DOS 6.2 costs $495 for the software developer’s kit. It includes all of the development software, Stacker 3.0, a certificate for 20 licenses, and documentation. Additional licenses cost from $25 (for one) and $5 (10,000). ROM-DOS with Stacker costs $40 (for one) and $8 (10,000).

Embedded DOS from General Software goes beyond DOS compatibility; it’s actually a real-time, multitasking OS compatible with MS-DOS 3.31. Like other embedded DOSs, it is bootable from PROM or disk. But this version of DOS is built on a preemptive multitasking kernel. It includes 48 services callable from C or assembly language and supports threads, timers, semaphores, and other services.

The file-management services are reentrant. File sharing and record locking are built-in. It supports DOS interrupts 21h through 29h, 2eh, and 2fh and runs .COM and .EXE programs generated with standard MS-DOS development tools. You choose various configuration options to create a desired system. A typical system requires a minimum of 128 kbytes of memory.

Embedded BIOS, a companion product that provides BIOS functions, is also reentrant. With it, you can fit both Embedded BIOS and Embedded DOS into a single 64-kbyte PROM. Embedded DOS costs $2500 for a full source kit and $995 for a partial source kit. Single licenses cost $10 ($4 for 10,000).

It’s not necessary to use a special ROM version of DOS to use it in embedded systems. You can place any disk files into PROM. A number of tools are available for this task. Most PC-based single-board-computer manufacturers have such tools for their products.

An example of such a tool is PromKit ($179) from Annabooks. PromKit is a set of programs that allows you to create PROM-based systems. Any file on a disk can be converted into a file residing within PROM. You can load OSs, applications, data files, and libraries into PROM.

This approach to embedding a PC allows you to develop your system on a disk-based desktop PC. Once the application is working properly, you transfer it to a diskless version without code modification. Your application program then loads from PROM just as it loaded from a disk.

PromKit includes a control program, located at an address, that allows the ROM-scan feature of XT- and AT-type machines to operate. This feature checks certain memory locations during the boot sequence; if it finds the appropriate pattern, the boot sequence installs the program. PromKit provides an extension to the normal floppy-disk driver, allowing PROM to replace the physical disk drive.

If you use DOS simply for loading a program, consider not using it at all. A package like C_thru_ROM ($495) from Datalight is a royalty-free product that allows you to take a program developed on the PC and transform it into a stand-alone application. The output of most DOS-based tools expects that DOS will be there to set up the system and allow the program to run. Without DOS, your application must initialize the system itself. These tools provide initialization and other services to let you place your program into PROM.

The ongoing flood of consumer products from the PC world continues to attract attention from embedded-system developers. It’s difficult to ignore low-cost, high-quality tools—and the hardware’s tremendous bang for the buck. As more people consider the PC for embedded systems, it will only get easier to use these products.

1. Shear, David, "Embedded systems developers embrace the PC architecture," EDN, March 3, 1994, pg 39.