Go Down

Topic: Arduino as a GPIB Controller (Read 12490 times) previous topic - next topic


Jun 27, 2010, 09:52 pm Last Edit: Jun 27, 2010, 09:52 pm by cmiyc Reason: 1
Anyone have ideas (or attempt) to use the Arduino as a GPIB Controller?  I am trying to use the Arduino to control some GPIB-based instruments.  It doesn't look like anyone has tried this before, but I thought I would ask anyway.
Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com


It is not difficult but there are a fair number of details to work through.
You need to implement the various state diagrams that
are in the GPIB specification. I did this on a 68HC11 a LONG time ago.

There were a couple of GPIB interface ICs that were used on
the GPIB interface cards that plugged into PCs. IIRC one was made by NEC.
Not sure if these are made anymore or if there are replacement ICs.

You don't need the IC but it could make the "glue" logic simpler.
In the October 1995 issue of Electronics World there was an article about
implementing IEEE. You could start there or with the specification or
with the IC manufacturer datasheet.

Could be a fun FPGA project to implement the various state diagrams.

(* jcl *)

www: http://www.wiblocks.com
twitter: http://twitter.com/wiblocks
blog: http://luciani.org


Oct 21, 2010, 07:46 am Last Edit: Oct 21, 2010, 08:07 am by QCK100 Reason: 1

I just ran into your post and was curious if you got any further. I am intending to take up the same task.

Do you have any thoughts on the GPIB side of the connection? If it should be conforming to standards, the GPIB port needs to be terminated towards VCC and GND with resistors in each direction and the Arduino would need to drive "open collector".

People have done this using non-Arduino ATMEGA boards so it should not be to challenging.

Regards, Jan


If you would like to try an FPGA Lattice is offering a dev kit for 29 and you can use their microcontroller core for non-commercial use.


I think that chip can do somewhat more than an arduino but the learning curve will be painful. I have one but need to get a parallel port to use it. ;)


Dec 21, 2010, 01:45 am Last Edit: Dec 21, 2010, 01:46 am by MurMan Reason: 1

Looks like it's time to raise this thread again.  I'm considering implementing a GPIB controller to work with some Tek equipment I've got.  From what I know of GPIB, it looks like a reasonable task for an Arduino.

What I haven't been able to find is a formal definition (state machine, timing, etc.) of the bus protocol.  Since this is for non-commercial use, I'd prefer to neither reverse-engineer it nor purchase the IEEE/IEC spec.  

Does anyone know of a public domain spec?  



Dec 21, 2010, 01:56 am Last Edit: Dec 21, 2010, 01:59 am by jluciani Reason: 1
Check the Electronics World article that I mentioned in my
original message for references.

A lot of interfaces were based on the NEC 7210 IC. If you
could dig up the datasheet for that part it may have the state

(* jcl *)



Thanks, jcl.  I looked at the NEC datasheet.  It documents the interface to the chip but not the chip's interface to GPIB.  

I couldn't get a link to the EW article.  


Dec 21, 2010, 02:24 am Last Edit: Dec 21, 2010, 02:56 am by cmiyc Reason: 1
Another approach I considered is looking for a FPGA implementation of GPIB.  I thought maybe someone has done the state machine in VHDL, which might give enough information.

If I had continued with my original project idea, I decided to implement the GPIB state machine in a FPGA.  But, life happened and I moved-on from the project.  (Though I still think it would be interesting to have some kind of GPIB interface, just don't have a need for it anymore.)
Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com


Here are the relevant references from the EW article --

ANSI/IEEE STD488.1 - 1987 Standard Digital Interface for Programming Instrumentation

ANSI/IEEE STD488.2 - 1987 IEEE Standard Codes, Formats, Protocols
and Common Commands for use with IEEE-488

Hewlett-Packard, Tutorial description of the Hewlett-Packard Interface Bus (1983)

Takeda Riken (Tokyo) Application note No. 2 - 1 GP-IB INTERFACE: General Description.

I had a copy of the spec at one time but that was a long time

(* jcl *)



You guys are fast.

Actually, I still think of it as HPIB.  Guess that dates me.  Used a lot of HP gear in the late 1970's to analyze process control problems.

I got a hit on "Tutorial description of the Hewlett-Packard Interface Bus" and found a copy.  It has the bus protocol documented pretty well.  



When we're fast we're slacking off ;)

(* jcl *)



Well, I've spent a few hours with the 178 page HP-IB tutorial that jcl referenced.  Plus a few docs, like the TEK device-specific commands for the scope and logic analyzer I'd like to interface to.

Some thoughts on building an interface:

1. The bus electical interface looks like it could be driven directly from the Arduino.  I'd probably buffer them anyway.
2. The bus byte transfer and data management protocols could be easily implemented in software.
3. Implementing IEEE 488.2 gets more complicated.  The HP doc describes the nine device states, but doesn't define the state machine.  Since this is what makes the bus recover from errors, I'd need the full documentation.  Probably would be flakey without doing it right.
4. Everything above the device message protocol (common commands, device commands, etc) would best be implemented in the host computer.  Probably would use Delphi, my fav dev environment.  I don't see anything too difficult, but it would be a lot of work.  Probably several times the effort to build the interface.

I'm coming to the conclusion that this is a much bigger project than I thought.  While it would be interesting to control a scope and logic analyzer, I don't have an overwhelming need that would justify this kind of effort.  Might be worthwhile as a team effort, but that's its own can-o-worms.

I'm going to sleep on it for a few days ...    :-/



Yeah, the same thoughts crossed my mind.  My need is to implement one controller connected to two talker/listeners.  Without the need for controller arbitration and with short cable runs, the bus would probably never get into most of the error states.  Plus, running the bus protocol in software would slow it down enough to eliminate timing issues.

If it didn't run reliably, I'm pretty sure I could track it down with the gear I've got.  And since this is for home lab use, there's always the reset button.

Maybe this project could be phased in ...  Darn you, Richard.


Are there controller chips like the NEC still available?
You see if you find some cards with socketed ICs ;)

IIRC a **long** time ago Capital Equipment Corp use
to sell these.

(* jcl *)



Are there controller chips like the NEC still available?

Using a controller chip would take all the fun out of this project.   ;D

Go Up