Program Interface

Early in the life of the Metrology project, it was clear that the software controlling the ranger would have to become a remote, embedded system, separate from the software used to control the entire system. This would require some sort of program interface that would allow another program to communicate with the ZY. The first interface used on the ZY was a binary interface over a serial port. This interface used function numbers, followed by a size word to specify the size of any following data stream. It was up to the function called to decode the data stream properly. This worked well with a serial port, but required a dedicated client program to operate. Later, when the hardware interface was changed to ethernet, I decided to scrap the binary interface and use an ASCII interface instead. In this interface, the ZY receives a command string, which essentially consists of a command name optionally followed by comma delimited parameters. The newline character is used as a delimiter between command strings. Such interfaces are common in the instrumentation world. Examples include HPIB (IEEE 488) interfaces, which commonly use an ASCII command interface, and HPGL, the HP plotting command language. The advantages of using such an interface include:

• Human readable. A telnet program can be used to connect to the ZY and manually send commands to it (see section 2.9 for an example of this). A user can also create batch files that the ZY can later read and execute. The ZY can also present a command line interface for trouble shooting purposes.
• Machine independent. Because the command and parameters are ASCII strings, this interface sidesteps the little-endian/ big/endian/data-alignment machine architecture issues. The ZY is responsible for decoding the parameters into numeric values (if needed), using its own library of functions. Likewise, the ZY's client (or user) is responsible for converting the responses from the ZY from ASCII to its own machine representation, if needed.

Figure 2.9: ZY Interface: Command Parser & Hash Table

The disadvantage to this interface is that it is potentially slower than a binary interface, as the ZY has to parse the command string, do a hash table lookup on the function for that command, and the handler function has to first convert all numerical parameters from ASCII to a numerical representation that the computer can use. I feel that the advantages far outweigh this potential disadvantage, particularly given the processing power available today. Actual measurements show that in reality this overhead is not significant: the overhead of reading and writing to a socket far exceeds the overhead of the numerical conversion and hash table lookup. Also, if I were to use a binary interface in a non architecture dependent way (such as with Sun RPCs) I would have to encode all data in a network byte order first, which also takes some time, and the overhead of reading and writing to the TCP socket would still be present. For the most part, the ZY interface is fast enough. In at least one instance, where large amounts of data must be sent as quickly as possible, these data are sent as an opaque, binary block. This allows the transfer to be performed with the fewest possible socket writes. For the moment, however, no attempt is made to make this binary data architecture independent.