March 1998, Issue 92

Picking a PC RTOS

Wow! So much has happened this month. I’m starting two new things—a new job and this column. I’m really excited about both. In fact, writing this column is part of my new job description.

And, I get the chance to work more with embedded systems at many levels. At the top end, we develop system-level modeling and verification software. In the middle, we’re working on PC/104 modules, which will be used in conjunction with off-the-shelf PC/104 module and software components to build embedded systems. And, we’re using some of our tools to develop synthesizable VHDL cores.

I’ve written for INK for a couple years now. You may have noticed my interests range from chip-level designs (e.g., FPGA-based robot controllers) to complete hardware- and software-based systems, like the MC68030 system described in INK 86–88.

So, I’m comfortable looking at different levels of detail. I also enjoy the contrast between the true parallelism of hardware objects with the flexibility and complexity of software objects running on a processor.

This meeting of software and hardware essentially describes Real-Time PC. In this column, the embedded PC meets the RTOS. I’ll be looking at how real-time embedded PCs solve problems in applications like robot controllers, data acquisition, and more.

Real-Time PC just ran a two-part RTOS 101 series (INK 90–91), introducing real-time operating systems, the terminology used, and the typical hardware found in an embedded PC. Those articles will serve as our launching point.

This month, I want to discuss the issues you need to consider in selecting an RTOS for your embedded-PC application. For my application, I’ll use a hypothetical robot controller that has some realistic requirements.

Next month, I’ll look at the next step—developing the software for the system. OK, let’s get on with it.