USBTMC Unwrapped

The USBTMC (USB Test and Measurement Class) and USBTMC-USB488 are two related USB (Universal Serial Bus) class specifications. They were officially adopted on December 22, 2002. The purpose of USBTMC is to describe the requirements for test-and-measurement devices with a USB interface.

USBTMC defines the protocol for exchanging messages between hosts and devices. It also defines how to abort a pending I/O operation, and how to clear a device.

Extending The Protocol

For its part, USBTMC-USB488 extends the protocol to devices that wish to communicate using messages that are based on the IEEE-488.1 and IEEE-488.2 standards.

The USB488 subclass adds items such as triggering, remote/local signaling, service requests, and communication protocols to properly detect IEEE-488.2 errors such as unterminated and interrupted conditions. Because of these useful additions, you should look for USB instruments that follow the USBTMC-USB488 standard.

Before diving into the details of USBTMC, let's review a few things about USB itself. Let's look at some of the key concepts about USB in order to help understand the rationale behind the development of the USBTMC standard.

USB contains one host and one or more peripherals. All traffic in USB is generated from the host. The host controller generates a heartbeat on the bus, which is called a frame; it's sent across the bus every 1-ms and is used to assist with scheduling and synchronization. For its part, USB 2.0 adds a concept called a microframe; it's generated every 0.125-ms.

Finally, USB uses endpoints. They describe a communication path from a host to a device. There are four different types of endpoints, each with different characteristics.

Guaranteed Bandwidth

Control endpoints have guaranteed bandwidth and are used to send small packets (typically for configuration and status communication flows). Interrupt endpoints also have guaranteed bandwidth (they're typically used to send very small packets on a periodic basis).

Isochronous endpoints have a guaranteed bandwidth, but have non-guaranteed data integrity (they're used to send time-critical information). Bulk endpoints are scheduled when bandwidth permits.

For more information, refer to a National Instruments USB tutorial on the company's Web site.

Now, a USBTMC-USB488 device typically contains four endpoints. These endpoints are the default control endpoint, the bulk-out endpoint, the bulk-in endpoint, and the interrupt-in endpoint. A list of messages that are sent across these endpoints is listed in the table here.

The default control endpoint is used to send out-of-band messages that require special synchronization, or need to be generated while I/O is currently in progress. Examples of control endpoint requests include device clears, I/O aborting, and serial polls.

Syncing Required

The synchronization is necessary to properly emulate GPIB, which uses a three-wire handshake that has the controller initiate an action by placing a command byte on the bus, with the device indicating the action has been completed by finishing the handshake. As USB doesn't let the device delay completing the handshake until the action is finished, the USBTMC standard converts these out-of-band messages into split transactions to guarantee proper synchronization.

The first part of a split transaction corresponds to the GPIB controller placing the data on the bus; it's known as the initiate action. The second part allows the controller to poll the device to determine whether the action has been completed.

The second endpoint is the bulk-out endpoint. A header is used on the bulk-out endpoint to provide information about the transfer to the device. The header is 12 bytes long, and consists of a message ID to identify transfer type, a tag to uniquely identify this message if it needs to be aborted, and a message-specific header.

One common message ID is a DEV_DEP_MSG_OUT (Device-Dependent Message Output). It's the equivalent of a GPIB write from the controller to the device. The message-specific header for this message ID contains a transfer count to indicate the total number of bytes in this transfer, and an end-of-message bit, which is used to emulate the GPIB EOI (End-or-Identify) signal to indicate whether the last byte of this transfer is the last byte in the total message.

The third endpoint is the bulk-in endpoint. The bulk-in endpoint is used to transmit data from the device to the host. It uses headers similar to the ones used by the bulk-out endpoint. All bulk-in endpoint transfers start with a bulk-out transfer that contains a message ID of DEV_DEP_MSG_IN (Device-Dependent Message Input).

The message-specific header contains a transfer count field to indicate the maximum number of bytes that the device can transfer to host. This guarantees that the device will never transfer more data than asked for by the instrument control application.

No Buffering

By doing this, the host doesn't need to buffer any data, and if the device needs to flush its output queue, there will be no data integrity problems. This type of interaction isn't necessary on GPIB, as the host reads data bytes one byte at a time and can stop reading data bytes from the device at any time.

The fourth endpoint is the interrupt-in endpoint. The purpose of this endpoint is to emulate the GPIB service request mechanism. It's optional for devices that don't wish to use service requests.

In GPIB, an SRQ (service request) line is used by a device to inform the controller that it requires service. As all traffic in USB is initiated by the host, an interrupt endpoint is used.

An interrupt endpoint is an endpoint type in USB that emulates a system interrupt. However, it isn't a real interrupt; it's actually a high-priority bulk-in endpoint that's polled at a periodic rate (typically once every n micro]frames. To work around the long first-byte latency of USB, USBTMC devices automatically serial-poll themselves when they need to request service, and return both the SRQ line and the status byte in a single transmission. The advantage is that the host can receive the status byte without generating another USB transaction.