Device drivers carry enough mystique that some programmers shy away from the subject. But with LynxOS, both beginners and experts can write device drivers. LynxOS makes installation especially easy — programmers can install drivers into the system without rebuilding the system kernel, which in turn allows online debugging.One of the DIAL Lidar project goals was to minimize development time by choosing a system that included all of the necessary device drivers. LynxOS was chosen partially because it satisfied that requirement. However, as the project progressed, the need to control a custom peripheral device presented an opportunity to build a custom device driver. We needed to design and build a digital circuit that could produce the timing signals necessary to operate a Neodymium YAG laser externally and to trigger a digitizing oscilloscope. The circuit needed to be programmable with respect both to delays between the various laser control pulses and to the repetition rate of the laser.
We chose to base the circuit on the familiar Intel 8253 timer chip, using only one of the 8253's three times. Its output, the "master" timing pulse, is routed to the custom digital circuitry that generates the various timing pulses for the laser and the digitizer. It is also connected to one of the bus interrupt lines. The master timing pulse triggers a chain of events external to the system computer. It also initiates the processing needed to capture and process the lidar return data.
The structure of this simple device driver resembles that of a standard UNIX driver. It has a top half consisting of the standard open, close, read, write, and ioctl calls. By using conventional UNIX I/O system calls, you can interface with the timing circuit hardware. The driver also has a bottom half that quickly responds to an interrupt from the timer. The sole function of the handler is the generation of a signal used to synchronize the lidar program's multiple tasks. In this driver, the coupling between the driver's top and bottom halves is very loose. No data needs to be input or output within the interrupt handler, nor does the top half of the driver process any input or output. It merely reads and writes the 8253's status and control registers.
Testing the card and driver software was also easy. We connected an oscilloscope to the timer output, to verify that we could control the operation of the 8253 using the appropriate driver calls. We checked the interrupt handler by starting up a task that writes to the screen after receiving a signal, and then signaling the task from the handler.