We're doing a project that requires a hard real-time operating system. The obvious alternative are
QNX looks like the way to go. Many safety-critical applications use QNX, and all the key components we need appear to be available.
Obtaining and installing QNX
QNX is available in a free version. The free version is x86 only, can't be used for a product offered for sale, and lacks the cross-development tools needed to generate code for small embedded machines like the StrongARM. None of those limitations are a problem for us, so we have access to a free real-time operating system.
QNX can be downloaded from the QNX "free downloads" page. Download "QNX Momentics ISO Non-Commercial Edition", which is a 200MB .iso file, (an image of a CD-ROM), check that it's valid with md5sum, and burn it to a CD-ROM. This produces a QNX boot and install CD-ROM.
Installation requires a reasonably standard x86 PC. The QNX boot CD-ROM can be tried on a machine without installing it to disk. This is fun to try; the result is a diskless "Internet appliance", quite capable of browsing the Web without touching the hard drive at all.
But to get anything useful done, you have to install it to disk. I'd recommend dedicating a machine to QNX. Dual boot is possible. While QNX can be installed under Windows, then booted from the boot disk and a Windows file system, that's not the way to go.
When you install QNX today, you get a desktop system with a reasonable, although uninspired, graphical user interface. All the Internet client stuff works fine; both the minimalist Voyager browser and Mozilla are provided and work. By default, the QNX installation is client-like, but you can start inetd and bring up the usual TCP/IP services like FTP. QNX also will mount NFS file systems over Ethernet.
What's going on underneath
QNX looks like a UNIX or Linux variant, but it's not. Underneath is a true microkernel, which does message passing, memory management, CPU dispatching, and very little else. Drivers, file systems, and networking are all in user processes, operating under memory protection.
Real-time applications under QNX consist of co-operating processes, each in its own address space, communicating via interprocess communication calls. This sounds ineffiicient, but QNX is optimized for interprocess communication above all else. An interprocess call costs about 150ns on a 2GHz machine. That speed makes it all work. QNX's own file system and network protocol stacks use that mechanism.
The development toolset is gcc-based, and there's full POSIX support, so the environment is very Linux-like. Bring up a command line window (called "terminal" in the GUI), and just pretend it's Linux. Underneath is the hard-real-time kernel, which, of course, is the whole point.
The Eclipse integrated development environment is being ported to QNX. There's a recent release. But I haven't tried it.
There's an "third party unsupported software" disk image for QNX, available from the QNX free downloads page. Download, check, burn to CD, and place in a QNX system's CD-ROM drive. Then start the "Install" utility from the GUI, and install any of the desired packages. Most of the GNU tools are there, including EMACS. (The standard install of QNX includes "vi", and a usable mouse-oriented editor.)
Java and Perl are available, although probably not that useful for our application.
QNX for vehicle control
QNX scales both up and down. It's usable as a disk-based desktop system, a CD-ROM based diskless system, a flash-memory based diskless system, and a ROM-based minimal controller. All versions can network and use the same API. This simplifies development.
The latest round of CMU NavLab code uses a message passing system very similar to that of QNX. After much struggling, they settled on fast interprocess message passing as the way modules of a driving system should intercommunicate. I agree. CMU used a mix of VxWorks and some version of Unix in their vehicles, then built on top of it a layer that looks much like QNX messaging - subroutine calls that send structures to other processes.
We'll have it easier there. The basic primitive in QNX is "call other process and wait". This normally doesn't cause a trip through the scheduler - control goes directly and immediately to the called process, with the attached data copied across the protection boundary. (Dave Cutler put a similar mechanism in NT, but it wasn't exported to the Win32 level, so nobody used it. It's not in Windows 2000) Waiting for a reply has a timeout mechanism, so you're not stuck if the other side hangs. The same mechanism can be used between QNX machines on a network.
Interfacing FireWire cameras requires a commercial QNX FireWire driver from MindReady, and I've ordered one.
A QNX programming guide, Getting Started with QNX Neutrino 2, is available. It's a bit expensive and hard to get; you have to order it from the author's company. But it's worth it.
Also see John Walker's QNX Tips.
20 December 2002
31 December 2002
Some early programming notes: