circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

May 2005, Issue 178

Network GPIB Controller


by Ron Battles, Patrick Jackson, & Scott Shumate

XML-RPC SERVER

The network GPIB controller requires a network server with a protocol that can manage GPIB requests and responses from remote clients. The primary requirements for the protocol are that it must be simple, it must operate reliably over an IP network, and it must be built on top of the ZTP TCP/IP protocol stack. We considered the implementation of a proprietary server and protocol, but because of its simplicity, broad platform support, and ease of implementation, we selected the XML-RPC for the task.

The XML-RPC protocol performs remote procedure calls using HTTP as a transport and XML as the data encoding. Requests are issued via a standard HTTP-POST request, normally to the /RPC2 URI path on the server. The server always sends a response to a request. An example XML-RPC request/response sequence for a GPIB send function is shown in Listings 1 and 2.

The availability of a web server in the ZTP package made it extremely easy to integrate our XML-RPC server because all of the HTTP processing was handled automatically. The XML-RPC server hooks into the ZTP web server by overriding the default POST processing function.

We considered using an off-the-shelf XML parser based on either the standardized DOM or SAX programming interfaces. Because parsers based on them are generic, they have fairly high run-time memory and code space requirements for an embedded application. Therefore, we implemented a custom XML parser that focuses on the XML parsing functionality needed by XML-RPC. The XML parser is designed to minimize the memory footprint as much as possible by parsing the XML in place inside the request buffer.

The procedure calls supported by the XML-RPC server map almost exactly to the standardized GPIB API defined by IEEE 488.2. This makes it extremely easy for someone familiar with GPIB to write client applications. The only difference is the mechanics of how procedures are called, not the procedure call format itself.