March 1998, Issue 92

Picking a PC RTOS

The software for this controller can roughly be split into three components—the controller task, gait generator, and servo drivers.

The controller thread, which starts the ball rolling, initializes the system and networking software and spawns the gait generator. The controller then waits for network connections and handles decoding the high-level commands, which are sent by a process on the Unix host (see Listing 1).

The gait generator coordinates the sequencing of the legs, as shown in Listing 2. Therefore, it needs to communicate with the controller thread and servo driver. The servo driver handles the timing of the servo pulses as you see in Listing 3.

Our RTOS needs to respond to timer interrupts with a latency of less than 100 ms. In addition, it should be multitasking, and in particular, it should be multithreaded. It also needs networking support, especially for TCP/IP, as well as a device driver for the serial port to handle PPP.

Obviously, our timing requirements are what make this a real-time project. To address this issue, we need to know what the RTOS’s interrupt latency is.

This figure essentially defines how efficiently the RTOS can respond to an interrupt and may include the time the RTOS or application interrupts are blocked during critical sections. The RTOS’s interrupt latency is usually given as a time measurement on a given processor architecture.

A proper specification includes the range of interrupt latency (i.e., with or without possible interrupt lock-out times). Typical values are 15–50 ms on a 33-MHz ’386. This amount of time should be enough to prevent our servos from destroying themselves. Figure 3 shows a timeline indicating the interrupt latency.