Putting The Scope To RealTime Linux

Tests to verify RealTime Linux's ability to generate uninterrupted square waves of 1ms and 800us period on the slowest machine I could find, an old 486-DX2 running 120MHz. This is to simulate a 'worst case' scenario. Faster machines will likely have better performance, in the form of less jitter.

The free version of Real-Time Linux (RTLinux) is available from rtlinux.org, and the commercial version all packaged together on a CD is available from rtlinux.com.

The version I used for these tests is miniRTL, basically a downloadable floppy disk image which you can boot to get an RTLinux kernel up with a minimum OS, which includes sshd, telnetd, httpd, a login environment, and most of the critical unix commands one needs to do basic operations.

Due to the changing universe, I thought I better keep my own snapshot of the miniRTL 3.0 floppy image that I used for these tests. You can download this and just dd(1) it to a floppy with the usual:

or if you are unix challenged, and only have a windows machine, you can download the image, and save it directly to a floppy using rawrite.exe. But for the latest version of miniRTL, you should go to rtlinux.org.

There is an example program that generates a square wave, precisely what I was looking for to see if a RTLinux, a full on multiuser operating system, can actually simulate what DOS can do; give a programmer the entire machine.

In DOS, when an application decides to take over the machine for time critical operations, DOS is usually completely usurped. It's surprising that, with RTLinux, you can actually keep the OS running (doing background processes and multiuser tasks) and still be able to have time critical software running.

After booting the mini-RTLinux floppy, I logged in as root, and invoked the 'pure_square' module to run these tests. Basically:

Then, it's just a matter of putting the scope probe on parallel port pin #2 to see the actual performance of the example module's ability to keep up a steady squarewave while the OS is running.

In this case, I invoked pure_square without any arguments, yielding a square wave with a default period of 2ms:

insmod pure_square
2mS/Div

Fig. 1 - System Idle.


Fig. 2 - Running 'cat /dev/fd0'.

The above shows two screenshots of the scope; one with the system idle at a bourne shell prompt with the default miniRTLinux daemons running in the background (Fig.1), and a second shot with a 'cat /dev/fd0' command outputting volumes of beeping binary data to the scrolling console screen (Fig. 2).

There were definitely no dropouts in the wave, regardless of what was going on with the OS; the squarewave was completely uninterrupted at all times. When the disk cat was started, there was no perceptible fluctuation in the wave; it was rock steady.

The next two screenshots show a closer view of the same output, but with the scope tracing at 10x higher speed; again, while the system is idle (Fig.3), and running the floppy 'cat' (Fig.4):

insmod pure_square
200uS/Div

Fig.3 - System Idle.


Fig.4 - Running 'cat /dev/fd0'.

Here, one can begin to see some 'jitter', where the edges are varying due to the system activity caused by the 'cat /dev/fd0', which is to be expected, considering there are concurrent IDE floppy disk reads happening here, along with a steadily scrolling console screen of the floppy's data, and a bleating speaker, due to the ASCII 'BEL' characters being cat'ed to the screen.

In the case of this particular machine, I came to find that the jitter was always about 45uS wide (or about +/- 23uS).

Never the less, the wave is never interrupted, seemed not to accumulate error, and the jitter is very slight.

In the next example, I decided to push the software to run at a higher frequency by using the optional 'period=[nS]' argument to the 'pure_square' module. In this case, 'insmod pure_square period=80000' was used.

Keep in mind these shots are taken at a much higher scan rate of the scope; 50uS (that's microseconds):

insmod pure_square period=80000


System Idle.
50uS/Div
System Idle.
20uS/Div


Running 'cat /dev/fd0'.
50uS/Div
Running 'cat /dev/fd0'.
20uS/Div

What's interesting here is that the same ~45us jitter is now a much larger component of the wave, but it's still not losing pulses, and the wave is overall staying in step; the wave does not appear to be accumulating error.



Back to my home page.