Difference between revisions of "Gpibgrok"

From sigrok
Jump to navigation Jump to search
(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...")
 
m
Line 2: Line 2:


== Motivation ==
== 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 [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip 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 [http://www.tek.com/datasheet/gpib-usb-adapter TEK-USB-444] from Tektronix, and it's ridiculously overpriced at around $740.
 
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 are so ubiquitous. The USB standards include a device class specifically made for test and measurement, called the [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip 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 [http://www.tek.com/datasheet/gpib-usb-adapter TEK-USB-444] from Tektronix, and it's ridiculously overpriced at around $740.


We think we can make a GPIB-USBTMC interface that is:
We think we can make a GPIB-USBTMC interface that is:
* 100% free and open source, hardware and software.
* 100% free and open source, hardware and firmware/software
* 100% standards-compliant
* 100% standards-compliant
* considerably cheaper than anything else out there (less than $50)
* 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 [http://elinux.org/Das_Oszi Das Oszi].
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 [http://elinux.org/Das_Oszi Das Oszi].
Line 13: Line 16:
== Hardware design ==
== Hardware design ==


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


== Software ==
== 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.
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 [http://home.dei.polimi.it/bellasi/lib/exe/fetch.php?media=students:gentile_finalreport.pdf thesis] on writing a USBTMC driver for the AVR32 architecture.


=== GPIB interface chips ===
=== GPIB interface chips ===


* HEF4738
* DS75160AN
* 96LS488
* NEC D7210C
* Philips/NXP HEF4738
* Philips/NXP HEF4738
* National DS75160AN
* National DS75160A*
* Fairchild 96LS488
* Fairchild 96LS488
* NEC uPD7210C/D
* NEC uPD7210C/D
* National NAT9914
* National NAT9914
(pretty much all of them are no longer available)
TODO: List buffer chips, which ''are'' still available.
== Resources ==
* Massimiliano Gentile's [http://home.dei.polimi.it/bellasi/lib/exe/fetch.php?media=students:gentile_finalreport.pdf thesis] on writing a USBTMC driver for the AVR32 architecture.

Revision as of 02:40, 26 May 2012

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 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 firmware/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 microcontroller 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.

GPIB interface chips

  • Philips/NXP HEF4738
  • National DS75160A*
  • Fairchild 96LS488
  • NEC uPD7210C/D
  • National NAT9914

(pretty much all of them are no longer available)

TODO: List buffer chips, which are still available.

Resources

  • Massimiliano Gentile's thesis on writing a USBTMC driver for the AVR32 architecture.
Retrieved from "https://sigrok.org/w/index.php?title=Gpibgrok&oldid=1957"