April 1998, Issue 93

Software Development for RTOSs

---

MOVING SOFTWARE

Software development for ETS is done using a Windows NT or 95 host. Since ETS is Win32 compatible, we can actually use the same 32-bit C and C++ compilers to develop code for ETS as we do for our regular Windows software development.

In particular, I used Visual C++ V.5.0 (VC), which is part of Visual Studio for Window 95 and NT. I used my notebook, which runs Windows 95, as the development host.

Since I’m more comfortable using command-line–oriented tools, I will use the command line version of VC to build my code. If you are more familiar with Visual Studio, you can use it instead. In V.9.0 of ETS, Phar Lap added support for building applications using VC under Visual Studio.

To start off, I developed a short Makefile, given in Listing 4a. Here we call cl, which is the command line interface to compiler and link using VC. By using the /C switch, we instruct cl to only compile each source module.

Once the modules are compiled into object modules, test1.obj, gait.obj and servo.obj, linkloc is used to link these modules, using the required ETS libraries into an executable image rctl1.exe. Linkloc also generates the symbol table for the debugger, which is loaded in the executable. A sample compile and link run under in a command line window under Windows 95, produces the output seen in Photo 1.

Once we have the executable, we need to get it to the target system. Phar Lap provides a monitor and kernel, which can be booted from a floppy. It’s called diskkern.bin and can be configured to load the application either from disk, or remotely over serial or parallel port.

In my example, I connected the target system to my notebook via a serial connection. The target system was another notebook—a 25-MHz 386sx-based notebook I keep around for just this purpose.

I use the target’s floppy drive to boot diskkern.bin configured to load the application from the serial port. Once the target has loaded the monitor from floppy, we can use the command C:/Users/cyliax/RCTL>runemb -com 1 rtcl1.exe to download and start executing my program.

GaitThread() simply cycles eight servo channels, one on each of the parallel ports data pins between full extensions of the actuator. I verified the timing with an oscilloscope, which also gave me a good indication of the jitter, which was minimal.

Now, doing the same thing for QNX, where we compile the program running on the OS, is a bit different. QNX can be configured as a full-featured RTOS.

Once installed on hard disk, QNX boots and presents a login screen. After supplying the login and password necessary to get into the system, we get a command-line prompt. (QNX also has a windowing system, Photon, for now I’m just going to focus on the command-line interface.)

The command-line interface in QNX is Unix-like, which is not surprising, since many software developers (me included) are familiar with Unix and feel mostly at home using arcane commands like vi and ls.

Also, QNX offers TCP/IP support, including remote login facilities for telnet, rlogin, and file-transfer facilities (e.g., FTP and rcp). In fact, once you have a QNX machine fully configured, it’s much like having a Unix machine or server.

There is, however, one major difference between Unix and QNX. QNX is a hard real-time OS. It has deterministic timing behavior for interrupt latency and operating system calls and implements preemptive multipriority scheduling. It also presents us with a rich set of process synchronization and communication mechanisms.

QNX is also a network distributed OS, which allows nodes to be used for remote execution of processes. Well, it’s probably overkill for this example, but it does a good job of illustrating the idea of host-based development.

Since QNX is so Unix like, I had to adapt the makefile I used for ETS (see Listing 4b). Here we use cc, the usual name for Unix-based C-compiler/linker front end, and instruct it to simply compile and link all modules and produce an output binary rctl1 with the -o flag. I also specified the -g flag to generate an extensive symbol table, to be used with the source-level debugger available under QNX.

Since QNX supports remote logins via TCP/IP, I can simply use telnet from my notebook to log in to the system and build my application using make. I use a wireless LAN PC Card in my notebook, so I can connect to the Ethernet in my house.

The target system is a 660-MHz 486DX2-based systems, with a small 120-Mb hard disk that hosts QNX OS and is wired into my Ethernet using a NE2000-compatible Ethernet card. Being able to log in to my target to develop real-time application from my notebook anywhere on my house or the Internet is quite nice.

Photo 2 shows what a session looks like. Once the application is built, the executable becomes one of the commands of the system. Simply by executing ./rctl1, we can generate waveforms under real-time control.

Since QNX’s timing resolution goes down to 500 ms, we can generate the timing pulses in 0.5-ms resolution. We can achieve all this, while still allowing remote users to login and compile applications.