Gpibgrok

From sigrok
Revision as of 00:27, 26 May 2012 by Bert (talk | contribs) (Created page with "This page documents some ideas and information for a GPIB-USBTMC hardware interface. == Motivation == There are many ways to communicate with devices that have a GPIB port, a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page documents some ideas and information for a GPIB-USBTMC hardware interface.

Motivation

There are many ways to communicate with devices that have a GPIB port, and sigrok aims to support as many of them as possible (see [IEEE-488]). However in this day and age the only reasonable interface for this would have to use a USB device port, since USB host ports these are so ubiquitous. The USB standards include a device class specifically made for test and measurement, called the USBTMC class. Yet most of the GPIB-USB interfaces available don't use this device class; they typically use either a proprietary protocol or serial emulation. There is only one GPIB-USBTMC interface that we know of: the TEK-USB-444 from Tektronix, and it's ridiculously overpriced at around $740.

We think we can make a GPIB-USBTMC interface that is:

  • 100% free and open source, hardware and software.
  • 100% standards-compliant
  • considerably cheaper than anything else out there (less than $50)

In addition, since we'd be making essentially a "server-side" i.e. USB device-side implementation of the USBTMC protocol, this code would be reusable in projects such as Das Oszi.

Hardware design

  • using an ARM Cortex-M3 CPU would get us:
    • built-in USB
    • plenty of horsepower to handle the throughput a GPIB device will reasonably need
    • many different implementations to choose from, and many inexpensive development boards
    • can start with an existing development board + GPIB connector
  • voltage levels on GPIB pins is "negative logic with standard TTL levels": true <= 0.8V, false >= 2.0V. (to be verified)

Software

Due to the long history of the IEEE-488 and SCPI standards, there are many devices out there supporting some earlier version of the protocol, and these will typically support commands that are vendor-specific, and syntax that is not compliant IEEE-488. Therefore supporting various device-specific or vendor-specific "quirks" will likely be a big part of real-world use-cases.

  • Massimiliano Gentile's thesis on writing a USBTMC driver for the AVR32 architecture.

GPIB interface chips

  • HEF4738
  • DS75160AN
  • 96LS488
  • NEC D7210C
  • Philips/NXP HEF4738
  • National DS75160AN
  • Fairchild 96LS488
  • NEC uPD7210C/D
  • National NAT9914