Introduction

We're doing a project that requires a hard real-time operating system. The obvious alternative are

• VxWorks - hard real time, no protected mode
• QNX - hard real time, protected mode
• RTLinux - hard real time, no protected mode for real-time tasks
• Windows XP Embedded - intended more for user-interface-heavy applications

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.

Development tools

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.

Useful notes

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

• QNX will share file systems using NFS if desired. Samba can be installed from the "3rd party CD", downloadable as an CD image from the QNX download site.
• QNX and its own programs understand Unicode, but not all the third-party software ported to it does. The QNX editor, ped, writes Unicode by default. This can create problems with some third-party utilities, one of them being Samba.
• Files open for writing are marked as damaged if QNX crashes. The default startup sequence doesn't run file system recovery. So it's sometimes necessary to boot from the CD, bring the system up from the CD alone, and run "chkfsys /dev/hd???", where "dev/hd???" refers to a partition found in /dev. This, too, affects Samba.
• Check the supported hardware list. Many display controllers are not well-supported. In practice, anything that supports VESA will run the Photon GUI adequately, but scrolling will be slow. QNX can be run on a reasonable range of desktops, but laptops for QNX are more difficult to find. We'll need laptop QNX capability for test and debug.

31 December 2002

Some early programming notes:

• The QNX messaging system works best if there is a clear hierarchy of client-server relationships. Client-server calls are easy. Server-client "callbacks" are possible, but can create deadlock problems and client-lookup problems.
• The "resource manager" system, which gives a service process an interface that looks like a file or a device, is very general. If something can meaningfully be talked to via "read" and 'write", that's usually the way to go.
• Multiple threads in a single process are fully supported, but the one-thread-per-process case is cleaner, because the message system gives you locking for free.
• Stack and heap growth require more attention than in most Linux programs. QNX has a quota mechanism, and in real-time programs, it's common to preallocate at startup and lock the limits.
• Forcing stack growth by allocating a huge (> 100K) array on the stack may generate a "segmentation fault" signal, even with unlimited quotas. The system doesn't like to create a sparse stack, apparently.
• The "gcc" compiler isn't entirely standard. QNX has done some work on it. They also offer a "QCC" compiler top level program, which knows more about QNX library locations and cross-compilation. QNX tech support suggests using
  "QCC -Vgcc_ntox86_gpp ... " instead of "gcc ... ", but I haven't tried this.
  Problems found so far:
  • Exceptions are off by default, silently. Use the gcc "-fexceptions" flag to turn them on.
  • "gcc" apparently ignores most, or all, of its usual environment variables. Use compiler flags instead.
  • Some of the STL libraries are in places "gcc" doesn't know about. Try adding the gcc flags
    -I/usr/include/g++-3 -I/usr/ntox86/include -I/usr/lib/gcc-lib/ntox86/2.95.3/include