AR488 Arduino-based GPIB adapter

[WaveyDipole]

Hi, this is very nice code, tnx! Is there any interest port it to ESP32 (if there is enough I/O), this will give native wlan support. I have tested adaper with ESP8266 and https://github.com/jeelabs/esp-link. Esp-link is nicest code what I have found for IP/Wlan<->serial bridge.

Ramppa

I had purchased an ESP32 to do some work with, but haven't got around to that yet. Having had a quick look at the documentation, it does seem that the ESP32 has more pins than the ESP8266. The ESP8266 does not have sufficient IO and I have done some work on a serial interconnect with an Arduino board but that work is not yet complete.

Although I need to have a look in more detail, there does appear to be a sufficient number of IO pins on the ESP32 board, so it might be possible to run the firmware directly on the ESP32 and have a web based config and telnet access over LAN. There are some questions, for example, does the ESP32 operate at 5v, or like the ESP8266, at  3.3v? Is 3.3v sufficient to drive the GPIB bus? Its certainly an interesting idea and I will do some more research.

[bitseeker]

Hi WD,

ESP32 can run on 2.3 V to 3.6 V, and 3.3 V is the recommended voltage with a power supply of at least 500 mA. I didn't see anything explicitly stating that the I/O is 5-volt tolerant, so assume 3.3 V.

GPIB Signal Type	DC Characteristics
Input Voltage High	VIH = 3.4 volts typical, 2.4 volts minimum
Input Voltage Low	VIL = 0.22 volts typical, 0.4 volts maximum
Input Current High	IIH = 2.5mA maximum
Input Current Low	VIL = -3.2mA maximum
Output Voltage High	VOH = 3.4 volts typical, 2.5 volts minimum
Output Voltage Low	VOL = 0.22 volts typical, 0.5 volts maximum
Output Current High	IOH = -5.2mA maximum
Output Current Low	IOL = 48mA maximum

So, ESP32 could probably receive OK, but there is some risk if a device on the bus goes too much higher than typical.

It looks like ESP32 max source is 20–40 mA (depending on power domain) and max sink is 28 mA. I don't know if that GPIB I_OL is often so high, maybe when there are many devices on the bus or at max bus length, so it may or may not be an issue.


Ref:
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf
http://www.interfacebus.com/Design_Connector_GPIB.html

[rhb]

The ESP32 is very cool.  I have several, but not had time to get acquainted yet.  But I question how useful a WiFi GPIB controller is given all the other wires required.  Perhaps for remote data logging using a directional antenna, but around a small  lab it's hard to see much benefit.

Now, a large student lab with multiple instruments and computer workstations is another matter.  I can see a lot of use for it in an academic setting.

[_Wim_]

The ESP32 is very cool.  I have several, but not had time to get acquainted yet.  But I question how useful a WiFi GPIB controller is given all the other wires required.  Perhaps for remote data logging using a directional antenna, but around a small  lab it's hard to see much benefit.

Now, a large student lab with multiple instruments and computer workstations is another matter.  I can see a lot of use for it in an academic setting.

Even in a small lab, I find the max USB cable length quite limiting if the equipment is in a rack or on a large shelf. Wired or wireless Ethernet is for me personally much more attractive. Wired has maybe still the advantage that power can be supplied also. The low cost POE switches found on Ali-express combined with a low-cost Ethernet GPIB adaptor seem like the ideal alternative to GBIB cabling equipment together.

[_Wim_]

Wired has maybe still the advantage that power can be supplied also. The low cost POE switches found on Ali-express combined with a low-cost Ethernet GPIB adaptor seem like the ideal alternative to GBIB cabling equipment together.

Something like this board, but with a GPIB connector already fitted...

https://wesp32.com/
or this
https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-source-hardware
https://www.olimex.com/Products/IoT/ESP32/ESP32-POE-ISO/open-source-hardware

[bitseeker]

Funny you should mention GPIB and Ethernet. I recently ran across an Arduino Leonardo ETH. They're discontinued, but essentially a standard Leonardo with onboard Ethernet and SD card reader (instead of using a separate Ethernet shield). It's almost a GPIB-Ethernet gateway with built-in log storage, just needs a shield for the GPIB connector.

[_Wim_]

Then if we add a Lipo to ensure the device keeps on logging to the SD card we arrive at something like this:
https://www.olimex.com/Products/IoT/ESP32/ESP32-EVB/open-source-hardware

Off course one of the goals should be that the final device is cheap enough so one can be fitted to each test instrument as an alternative to GPIB wiring and a single GPIB adaptor.

[bitseeker]

That eval. board is not a bad price when compared to how expensive GPIB interfaces are. However, making a dedicated board would be more space efficient for use directly on every device as you describe.

Since I already have GPIB cables between instruments, I might one day turn a Leonardo ETH into an Ethernet gateway. I imagine the AR-488 firmware would port over to the 32u4 without too much trouble. Then, it's a question whether there's enough code space for the Ethernet part.

[_Wim_]

Since I already have GPIB cables between instruments, I might one day turn a Leonardo ETH into an Ethernet gateway. I imagine the AR-488 firmware would port over to the 32u4 without too much trouble. Then, it's a question whether there's enough code space for the Ethernet part.

From what I have read, I think the hardware of the arduino as it is cannot handle daisy chained devices on GPIB. For this to work, additional hardware needs to be implemented.

[rhb]

Since I already have GPIB cables between instruments, I might one day turn a Leonardo ETH into an Ethernet gateway. I imagine the AR-488 firmware would port over to the 32u4 without too much trouble. Then, it's a question whether there's enough code space for the Ethernet part.

From what I have read, I think the hardware of the arduino as it is cannot handle daisy chained devices on GPIB. For this to work, additional hardware needs to be implemented.

This comes up about every other day based on someone's experience using another MCU, especially PICs.  All MCUs are not the same.

It helps to read the datasheets and the GPIB electrical spec.  One can use dedicated GPIB drivers, but it's not needed with the parts used in the Uno and Mega.  They only provide 40 mA of drive  rather than the 48 mA of the GPIB spec.  So they won't drive a full bus load of 16 devices and there are some other issues with certain software packages such as EZGPIB, but all this is covered rather well in the AR488 manual.

While I'm not an Arduino fan, I've developed a good deal more respect for them after using one of vindoline's boards  to read a pair of 34401As continuously for 6 days.

[Kean]

It helps to read the datasheets and the GPIB electrical spec.

Yes, it does.   

The 40mA of drive on the ATmega is the "absolute maximum" per pin, and there is also an absolute maximum of 200mA for the whole IC.  It is a bad idea to push the output FETs if you want to keep the chip working long term, so best to keep to only a few devices on the bus.  Another point is that you aren't guaranteed to meet the GPIB spec for low level output voltage (V_OL) at more than 10mA or so, thus leading to a good chance of other problems.

[coromonadalix]

75161 or 75162 type line drivers,

The drivers are designed to handle sink-current loads up to 48 mA

https://www.ti.com/lit/ds/symlink/sn75als161.pdf

[Kean]

75161 or 75162 type line drivers could pump it to 48 ma ...
https://www.ti.com/lit/ds/symlink/sn75als161.pdf

Exactly!  Usually only needed when running with a loaded bus (4+ devices).  In which case you must have lots of test equiment, and will probably buy a real GPIB controller...

[coromonadalix]

The AR488 is a great solution, but if people(s) need to adress more than 4 units, we have to upgrade the ar488 project ... and adding them in soic packages, i dont think the ar488 project would cost a fortune to make/adapt ?  or make a daughter board or a shield ??

[bitseeker]

An Uno-compatible shield with the connector and line drivers on it would be neat for experimenting with different Arduino boards.

[rhb]

WaveyDipole

I'm looking at the Mega 2560 wiring.  Is there any reason  not use 24 pins on the two row header at the end?  It's been a couple of years since I looked at the board details, but a 24 pin ribbon cable on the 2 x 18 header at the end feeding the GPIB bus connectors via a ribbon cable seems a lot cleaner than the current wiring for the 2560.  Though perhaps not as convenient if one wants to use a stock LCD display.

Is there a pin assignment constraint that prevents doing that?  All MCUs have various constraints on which pins you can use for what and sorting out usable connections can be a real headache.  You're obviously very aware of the issues.

I've ordered the minimal form factor Mega 2560 boards, but they will take a while to arrive.  I've got a bunch of regular Mega 2560 boards, but only one prototype board.  I'd like to get an initial prototype with an RTC and CH11 T&H sensor put together this weekend.  With luck my Si7021s will show up before Sunday and I can assemble and test  both RTCs and both T&H sensors.  If I *really* get lucky I might have all 4 permutations working by the end of next week.

Are there GPIB pins with special needs?  I'd like to create an alternative layout for attaching a ribbon cable using the dual row Mega connector with some diverted wires if required. 

I looked at the Uno wiring again and it doesn't look as if it is possible to add both the the RTC and a T&H sensor to an Uno based unit.  Relative to the cost of commercial GPIB-USB interfaces, the extra cost of a Mega hardly matters.

Thanks a lot.

Have Fun!
Reg

[coromonadalix]

@ rhb   read the previous post,  the pinout is mentioned  and the reasons why too

https://github.com/Twilight-Logic/AR488/blob/master/AR488-manual.pdf

see post #161

[rhb]

Where do you think I got the current pinout information from?

I don't want an LCD, just an RTC and a pair of T&H sensors.  I am *not* suggesting WaveyDipole should change his version.  I'm asking if there is a gotcha in the Mega pin choices he made, i.e. certain signals for GPIB can *only* be generated by certain pins on the Mega.

I'd like to be able to simply connect a 2 x 12 ribbon cable header connector to an Arduino Mega with a series of 2 x 12 Centronics connectors and have it all wired up using IDC connectors.

[coromonadalix]

Well  i think you know  how, normally you can rewite his code to asign the pins you want to use, or make an shield / daughter board ??

Wavey did tell the reasons has you know / read for the pins used ....  what more do you want to know ?

Its not a rant or any argument war.

And i will say it again,  it is not this original thread mission, you have to take it to a new thread.


I'm trying myself to build an arduino gpib interface,  have problems to find a pcb mount gpib connector here ......  i'm trying to understand the provided code(s) and read arduinos boards pro's and con's.

I wanted to play with my teensy 3.2 and my mega2560 before the code was re-written by wavey

You have a very powerful teensy 4 who just got out ... you have a very good forum help on pjrc ...  still pro's and con's too.


@RHB   Maybe im wrong,  but you seem to need someone to fork a arduino code for you    You tell what you need or desire but do you provide some starting points / code snippets etc ... ?

I can't  since im very bad at coding myself, i read and i try to understand, thats all i can contribute.

[artag]

I don't really see the point of driving a 488 bus full of instruments. These arduino-based interfaces are cheaper than the 488 cables, and USB cables are more convenient (thinner). So if you want to control multiple instruments, just give them a USB interface each.

[rhb]

There is a SCPI command GET which will execute a synchronized measurement on multiple devices on the GPIB bus.  It is unlikely that attempting that with multiple GPIB-USB devices would achieve as tight a synchronization. This can be very important if one meter is reading the voltage and the other is reading the current under dynamic load conditions.

If you have a stack of DMMs, being able to read all of the stack using a single GPIB-USB adaptor and  12" of ribbon cable and an IDC Centronics connector per meter is a lot cheaper and more convenient.  And then there is the minor detail of just how many USB serial ports will the OS support. At the moment I have 13 instruments with GPIB interfaces.  The number is going to get larger, not smaller.  I'm sure I'll need more than one GPIB-USB interface.  How many is yet to be determined.

Code forks mean that there is another place that the same bug has to be fixed.  I am prepared to go to a *lot* of trouble to avoid code forks.  Spend a few years maintaining a pair of 300KLOC forks so they work together and you'll understand why I don't like them.  Or 500KLOC which was copy-paste-modified over a dozen times so you have a dozen or more places the same bug has to be fixed each time someone finds a bug.

My concern is some subtle GPIB electrical interface requirement that can only be satisfied by certain pins on the Arduino.  Very often you only learn about those the hard way trying to figure out why it won't work.

Old guys who have spent lots of time battling terminal, modem and printer configurations worry about such things.  Not knowing about the footnote on page 644 of a 1786 page manual can eat more of your life than you can imagine.  Nothing triggered as much fear and dread in a senior sys admin 35 years ago as a nice shiny $100K graphics terminal that one of the users had just bought and wants connected to do DMA out of main memory of a super computer to the graphics processor.  Imagine having to get an nVidia card with no software drivers working.  You're the admin, you're the one who gets to write the driver for your super computer, not the vendors.  Documentation, you don't get no stinking documentation.  That's proprietary.

[coromonadalix]

I do understand all of that    BUT  the arduino ar488 project is a somewhat cheap substitute to really expensives  usb-gpib adapters .. like the famously cloned Agilent, or an National Instrument gpib  etc...

I would advise caution using this on one or many instruments in a chain .. with known current drive limitations for the outputs.

On many occasions you had timing issues and small nicks between many brands, and the updated codes helped a lot fom Wavey

Thats all   Im just saying its too easy to forget thoses things and have many problems happening while doing seroius jobs.

Unless someone wants to upgrade it to an industrial device, adding input/output protections, surge protectors,  emi rfi shielding etc ...   it wont be a simple project anymore.


@rhb   Did you tried using hp main frame like the 34970 ??   you had other main frames sold recently on fleabay  for very cheap prices ...

[rhb]

40 mA vs 48 mA is not a big limitation.  It's 3 fewer devices on the bus.  Except for that, the Mega meets all the IEEE-488 specs so far as I can tell.  My biggest concern is I/Os which are only available on certain pins of the Mega.  In particular the pins for I2C for the RTC and T&H sensors.

I ignored the Arduino for many years because it targeted non-engineers.  But I've developed much greater appreciation for them because they interface well with TTL and are very cheap.

I'm probably going to use two Megas.  One to control the RF deck and one to control the DMM deck.  The DMM deck will get much heavier use scanning voltage references than the RF deck which will almost exclusively be used for doing cals on the RF gear.

WaveyDipole and I have exchanged some PMs on this.  Nothing is decided, but it looks as if I can make what I'm doing fit in to the existing framework.  The price of the Keysight and National Instruments interfaces is ridiculous.  There is just not that much hardware in them.  The Prologix syntax that WaveyDipole copied lends itself to adding "++time", "++temp", "++humid",  "++relay in n",  etc, very neatly.  If it is "#ifdef MEGA" it doesn't break anything if someone is using an Uno.

I'm not looking for someone to do any of what I want.  I'm trying to make sure that what I do doesn't break something I don't know about. And as a point of professional pride, when I get done it should be impossible for anyone else to tell what I wrote and what WaveyDipole wrote.

On my first contract job for a major oil company, I wrote a couple of 15KLOC libraries which *never* had a bug reported against them in 12-15 years of deployment.  The only change ever made was when Sun released a C standard library which failed to set errno properly after a call to getcwd(3c).  That project was a 500KLOC port from VMS to Unix.  After the first year of deployment I prepared the release notes.  We had under a dozen user submitted bug reports.  As we added new programs to the package the bug count went down from there.  We had a huge regression test suite that we ran every time we did a build which checked everything we knew to check. After 7 years, a merger in 1999 ended support for the package, but because it was so reliable it ran on until it was simply obsolete. 

I ported it to 6 different Unix workstations.  I don't know how many it was actually supported on as I left to avoid suffering through the misery of another layoff.  The new client had an unannounced  layoff the day after I got there.

We had done HP and AIX ports following the initial Intergraph and Sun ports.  I did the Ultrix and Irix ports as an afternoon lark one day when I didn't have anything to do.  All the business affiliates insisted on buying whatever they wanted.  Our policy was, "Yes, sir.  We can provide that on any system you choose.  You merely need to pay for the 2 weeks of staff time required to verify that the results are correct."  The code had two "#ifdef"s, byte order and "RECL=" in words or bytes.  Pretty good for a dusty deck FORTRAN port to 6 Unix platforms from VMS.  I wrote a program which converted all the VAX run time library calls to functions we wrote using the C standard library in all 500KLOC in a single run.  It checked the code out of SCCS, converted it and checked it back in.

There is *no* excuse for buggy software.  Buggy production grade software is a clear demonstration of incompetence.  Research code is a bit different.  But there is a factor of 3-4x difference in the labor required to write research code vs production code.  Fred Brooks wrote very eloquently on the topic in "The Mythical Man Month".

But to reiterate, I'm still trying to figure out *what* I'm going to do.  And I'm looking for obscure edge cases.

[artag]

I agree there are certain GPIB operations that wouldn't work well on multiple USB connections, or even ethernet. For those, you probably do need a traditional interface with proper buffering. But I'm not convinced they're terribly important for a random collection of old test instruments - I can see their utility in a carefully orchestrated ATE setup but that's not what I'm running. I just want a convenient way to extract and log data from instruments too old to have USB or ethernet - and if they did have they, they still wouldn't have the GPIB operations like device to device transfer or parallel polling.

So I think worrying about that buffering on a cheap-as-chips interface is overthink. If I needed to do that I'd probably be willing to spend the money on a full-on interface. In fact I picked up an NI-USB interface for peanuts recently - but I like the open source possibilities of this design better. Another option is to get one of the much cheaper ISA or PCI interfaces, put it in a dedicated machine with ethernet, and build it into an intelligent bus controller that does everything you want. I have most of the bits stacking up for this too - just needs a convenient old mini-ITX board with pci to fit the case !

I believe the popular Prologix interface also has no 161 buffers, at least in the USB implementation. There's also a relatively cheap (cheaper than prologix) device by Galvant that _does_ have buffers but unfortunately uses a Microchip controller with its restrictive compiler. I prefer gcc and AVR. I don't want my instruments on wifi, I prefer the predictability of wired so esp8266 is unappealing (though esp32 can support a wired ethernet interface - it's just that there isn't a cheap off the shelf module that offers that).

A USB network can get a bit clumsy but it has thin wires, self-powered interfaces and easily overreaches the 31 device limitation of GPIB. So I'd prefer ethernet but I'll put up with USB for the wiring convenience.

I don't, however, have any problem forking the code. It's convenient to be able to pick up improvements to the main branch but in practice, onmce it's working, it's likely to stay untouched. The most likely area of incompatibility is in pin assignments - I want to build a version that avoids the serial interface and uses a 32u4, perhaps based on a simple PCB adapter between the footprint of a 488 plug and the footprint of an arduino pro micro. It may be that WaveyDipole's work to implement it for 2560 has already made this part more portable : I suggest it could eventually just be an included file of #defines rather than conditionals.

And I *am* an old guy. I have alkl those concerns about doing it properly. But this, I think, is an occasion where doing a carefully-selected partial implementation wins for some specific - but very common - cases.

[rhb]

AR488 is a FW stack.  What particular HW is used is a different matter.  My goal is for the FW stack to be absolutely bullet proof,  do *anything* that makes sense and be trivially configurable to whatever HW the user chose whether it's a single Uno and DMM or something very exotic.

I happen to be at the 3 sigma high end wanting to switch an 8560A, 8566B, 8648C, 438A w/ 8481D & 8482A, 5386A and GPSDO for a full calibration test.  I also want to scan multiple voltage references 24 x 7 over multiyear durations while cycling an environmental chamber.

Very likely I'll use a Pi as the data logger, but I've got a lot of software to write to interface the Arduino to the 44421A relay board, T & H, RTC , etc first.  So all in due time.  Right now I'm analyzing the data from my USA CAl Club: Round 2 run.

For someone installing AR488 on an Uno or Mega using the  Arduino IDE, nothing will look any different other than the presence of an #ifdef which I'll use in a traditional Makefile to include all the exotic options.

I recently acquired a 16500 logic analyzer, so I'll be writing a test suite that exercises the full functionality of the AR488 FW stack and checks it using the LA for correctness.  It will all get done when I get it done, so don't expect me to put in 40+ hr weeks to meet some deadline.

While it's not needed for most use cases, it would be nice if someone spun an OSHW board using the TI GPIB interface chips on an Arduino shield footprint.  I don't have any PCB layout tool skills.  Everyone has their limitations.  I'm no exception.

Have Fun!
Reg