No matter what bus is used to control instruments within a test setup, the commands that initiate this control must be defined. Commands that control the parallel port send data in a "bit-banged" format. Both the RS-232 serial bus and the IEEE-488 bus transmit serial strings of character data.
The IEEE-488 standard governs the bus itself, not the kinds of messages sent over it. Despite this, there's some agreement as to what types of messages are sent. For example, modern DVMs use nearly identical command sets, which saves customers development time. But for older or nonstandard instruments, little or no agreement exists. The Standard Commands for Programmable Instruments (SCPI) is an attempt to increase the agreement within command sets. If the SCPI doesn't include suitable commands for your instrument, then you will have to invent part or all of a command language unique to that instrument. SCPI is preferred, of course, because it enables those who use the instrument to more quickly understand its operation.
It's best to develop software in small steps and in a logical progression. Make sure to partition the software so that future changes can be readily implemented. Good software development begins with the command processor, which is a collection of software routines that interpret text commands and control the hardware accordingly. One possible approach is to have the command processor initially accept commands only via the RS-232 serial port, permitting the development of low-level subroutines and the command processor itself to be used to test them. Gradually, device drivers can be added for each of the subsystems (e.g., the IEEE-488 controller, the analog-to-digital converter, and the digital I/O), always with the working code to fall back on if problems arise.
This modular approach to software design facilitates initial development as well as future software changes, especially if the person creating the changes isn't the original developer. When software is developed by organizing it into independent device drivers, new devices to test can be supported quite quickly. Changes to one part of the software don't change other unrelated parts because the modular structure partitions the code aggressively, in anticipation of future changes.
Aside from proving useful at the beginning to develop the software, the RS-232 port is a handy diagnostic tool for the final phase of the project in which the software is debugged. Even if the final design of the tester doesn't provide customer access to the RS-232 port, it can still function as an effective and inexpensive portal for status messages that are useful to a field technician.
When writing software, reserve one memory location as a diagnostic enable and another as a diagnostic status indicator. Keep these locations in the final version of the software. If a customer encounters a problem, these diagnostic tools may provide valuable information.
A watchdog timer is a useful device that resets the microprocessor if it gets stuck in an infinite loop. Software must service the watchdog timer at regular intervals to prevent its timer from expiring. When the watchdog timer does expire, indicating the microprocessor is stuck in an infinite loop, it resets the instrument's microprocessor, restoring it to a known operating state. The watchdog-timer reset can initiate the printing of the diagnostic status indicator contents, revealing which part of the software may be responsible for the crash. Only the input, output, and delay subroutines need to service the watchdog, preventing its timer from expiring. As a general rule, the software spends most of its time in its input or output subroutines. Therefore, these subroutines are the best place to service the watchdog timer.
Although it might be obvious, it's well worth noting that you have to frequently make backup copies of the source code. To save time, every time you program a new ROM image, copy only the changed files. Also, make sure that you have a way to patch ROM code. Even with a limited amount of memory available for patches, the time saved for each instance that you compose, compile, and test code is significant, particularly during marathon development sessions.
Reference:
- Axelson, Jan, "Parallel Port Complete," Lakeview Research, 1999, p. 343.