AR488 Arduino-based GPIB adapter

[rhb]

FWIW I read all the Mega version code today.  It's *really* well written.  So it will be a real pleasure to work with. 

Unless you've done it, you can't imagine what it's like to have to debug and support 750KOC of scientist written software in which the only comments are the author's name.  When there are half a dozen algorithms in the literature for doing something, it's a lot of work to figure out from the code which one is being used.

The author of one 50KLOC program reported it crashed.  I tracked it down to an uninitialized variable.  He couldn't figure out what the variable was, so I never fixed it.  He was the only user.

I got my Si7021 boards today, so I hope to have a AR488 Mega based GPIB-USB adaptor working soon with the time, temperature and humidity reporting via Prologix style commands.

Of course, neither of the two RTC nor the Si7021 boards came with *any* documentation :-(

So I get to play hunt the wumpus on the internet looking for documentation.

[bitseeker]

Hunt the wumpus. Classic!

[rhb]

Hunt the wumpus. Classic!

LoL!  Living as I do among a great mass of semi-literate hillbillies, it's a great delight to converse with literate people who recognize obscure references.

I rather dread fixing the Tempduino bug. My 2424.378 C readings at the end of  the PX/FX ratio run suggest a buffer pointer  bug in something which will be difficult to work on.  Could you post a sample of Tempduino log output  you encountered? 

The Wire libraries are in stark contrast to the careful style of the AR488 code.  Error checking?  We don't need no stinking error checking! I rather fear that will require a code fork. Past experience with code cowboys has not been good.  I'd fix it and they'd break it, again. And again.

Fortunately, if you go through adding error handling, most things become much more reliable without doing anything more difficult than suffering the tedium of writing all the error return handling.

But at this point, all I can do is hope.

[WaveyDipole]

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?  A

Since the possibility of adding a touch display was mentioned, I looked into the displays available for the Mega and it turned out that the touch display uses that two row header. On the other hand, shields tend to use the side connectors and the basic two row text display can make use of any available pins. There was no possible solution that could satisfy keeping both the two row connector and sufficient pins for shields free. I was also unsure about using the pins designated for the SPI bus for PCINTs (50-53) so in the end I decided to go with leaving the end connector free. However, *theoretically* there is no reason that the GPIB controls pins could not be confined to the two-row header. On the UNO, pins 11 and 12 are also allocated to MOSI and MISO but using them for GPIB control seems to have had no ill effect on being able to use the SPI connector to program the board with an AVR programmer. I therefore suspect that there should be no problem using pins 50-53, but not having tested it, at this time I can't say for sure.

The port layout is still a bit awkward as each register port corresponds to 4 pins on each row so to use one port you have to use 4 pins across two rows rather than 8 consecutive pins on one row. Since a couple of pins with PCINTs are required, the GPIB control pins would perhaps have to occupy the left hand side (39-53 and 38-52) and the remaining pins could be used for other purposes including to control GPIB Bus driver chips. I could implement the code so that the current layout and the two row connector layout are selectable by means of a #define directive providing the user/developer with the option to use either.

On another note, regarding the ESP32, it seems that the ESP32 board documentation makes no mention of PCINTs or pin register ports. Interrupt handling is provided but seems to be implemented somewhat differently and it seems that pins would have to be managed using pinMode(), digitalWrite() and digitalRead() methods which are slower than direct port manipulation that is being presently used to maximise performance. The current code would therefore need a substantial re-write and performance may be impacted somewhat, but I do intend to do some work on it in due course.

For the present, I would like to focus on the Mega and complete what I have planned as well as include any further suggestions.

With regards to that, I found the multiple GPIB buses idea interesting. Theoretically one should be able to accommodate up to 3 GPIB ports on the mega with a handful of pins to spare. Whether that would mean having 3 separate GPIB buses or just one bus with 3 ports I'm not yet sure, but it would certainly allow significantly more instruments to be connected. If this is something that is likely to be useful, then I will consider adding that as a feature. It does have an impact on the use of the two row header so implementation would need some careful thought, especially if the flexibility of using different layouts as discussed above is to be maintained.

[rhb]

I had a long look at the Uno and Mega pin layout yesterday and am pretty much in agreement with your choices.  It *might* be desirable to free up the 8 ADC pins, but for now I'm going to stick with what you've done and focus on adding an RTC and T&H sensor.  I now have all my parts except for documentation, so I'm hoping that perhaps by the end of the week I'll have it working.  But a lot depends on how much work I need to do on the Wire library for I2C support.

On general principle I'd like to merge the Uno and Mega versions so there is only a single point of maintenance.  So I'll be looking closely at what is needed to achieve that.  I also *very* much want to implement "++lon" for use as part of a test harness.

It was a huge pleasure reading your code.  I wish I could say the same for the Wire library.

AR488 looks quite suitable as the base for a GPIB-USB interface that can equal or exceed anything on the market.  For a wide range of reasons, I think that ethernet connectivity is best done with a Pi or Beagle.  The main reason being that for multiyear logging of a suite of voltage references using a 44421A relay card for switching it makes more sense from a power consumption basis to record the data on something like a Pi. It also allows running everything from some sealed lead acid batteries.

BTW the 44421A needs 9 pins per board to select any of 20 inputs.  The thermal EMF of the relays is specified at under 1 uV, but I'm considering bonding an aluminum plate to the relays with thermal silicone sheeting and then monitoring the temperature with thermistors and the Arduino ADC inputs.  With appropriate care I think that it might be possible to get well below 1 ppm error.

[sixtimesseven]

Nice Work!

Could I suggest looking into supporting ESP8266 or even better ESP32 boards as well? This would open the possibility of connecting via wifi and in the case of the ESP32, bluethooth as well

I designed a little board featuring a ESP32 and optionally the proper 488 line drivers but I have not been able to test it so far. To much other stuff to do

https://github.com/sixtemesseven/WGPIB

[rhb]

If I may ask the obvious.

Why not use the AR488 via USB from an ESP32?

To my mind, the whole point of using an Arduino is it is TTL compatible.  Aside from pin assignments and writing WiFi services, the AR488 code should be pretty straight forward to run on an ESP32.

TANSTAFL.  I would never use wireless if a wire is convenient.  It consumes spectrum I might need for something else.

The ESP8266 is a power hog.  So I have a problem seeing any benefit to using that.  It's like WiFi security cameras.  What's the point of wireless data if you still have to run power?  PoE is much more sensible.

But I'm still left with the question, what GPIB instrument needs a wireless connection and why?  Cite a use case.

[WaveyDipole]

On general principle I'd like to merge the Uno and Mega versions so there is only a single point of maintenance.  So I'll be looking closely at what is needed to achieve that.

Funnily enough I was thinking the same today and it would be a good idea to do this sooner rather than later, maintenance being the key factor. On the other hand, I envisage that there will be a lot of code that will be applicable exclusively to the Mega only which will probably take a rather different direction so at this point I am undecided but considering it.

I also *very* much want to implement "++lon" for use as part of a test harness.

I had fun an games with that and could not get it to work reliably so I shelved it for later, but was going to revisit it at some point. If I have time over the next few days I will have another look at it.

For a wide range of reasons, I think that ethernet connectivity is best done with a Pi or Beagle.

I had considered the the possiblility of using an Ethernet shield and maybe implementing LXI, but that was something to consider further down the road and only possible on the Mega so I read this comment with interest. Of course, the PI has the advantage of having Ethernet already built in.

Could I suggest looking into supporting ESP8266 or even better ESP32 boards as well? This would open the possibility of connecting via wifi and in the case of the ESP32, bluethooth as well

This is currently under consideration and some work has already been done to support the ESP8266 connected via serial to the Arduino - it doesn't have enough GPIO pins to drive the GPIB bus directly - but it is still a work in progress. The ESP32 is also being considered.

[rhb]

A big advantage to using a Pi or Beagle for ethernet is that a single Pi with a USB hub could service a lot of instruments and also provide backup archival storage.

An ethernet shield on an Arduino is limited to the GPIB bus capacity whereas with multiple AR488 interfaces you could support many more.  It also doesn't require any extra work.  I suspect that trying to cram all of AR488 *and* ethernet into a Mega would be challenging.

Now to find RTC documentation for the DS1302 and DS3231 w/ an Atmel832.

[maxwell3e10]

I haven't yet tested WaveyDipole Bluetooth interface. But if it works reliably, I am leaning toward minimalistic Pro Mini 5V board, since one wouldn't need a permanent USB connection, only for programming. These boards (as well as nano) also have extra A6 and A7 pins. Using one of the alternative Wire libraries it should be possible to implement I2C on them and then have an interface to BME280 sensor and DS3231 RTC. If by some magic the whole thing can be powered by stealing power from the instrument GPIB lines, it would be a complete solution.

[texaspyro]

Here's a post with a link to my GPIB code.  It runs on a ATMEGA 2561 and emulates a Prologix adapter.   

https://www.eevblog.com/forum/projects/atmega-gpib-yet-another-diy-gpib-to-usb-project/msg1298075/#msg1298075

The code in the link to Github  has some I2C routines (in twi.c and twi.h)

[mlefe]

Guys, I might have some time to try to port this to the blue pill (stm32f103c8t).
Is anybody working on this? (I want to avoid the double work...)

[coromonadalix]

not to my knowledge

Would be nice to have one ported to the bluepill

[rhb]

Before you start to port any GPIB-USB code to the STM32 line I suggest you read the electrical specifications for the IEEE-488 bus.

Can it be done?  Yes.  But you will spend as much money on the GPIB bus drivers as the price of an Arduino.  GPIB is a 5 V TTL level bus and requires 3 mA per pin per device on the bus for reliable operation.  The STM32 cannot provide that.  You'll also need to make a board for the drivers unless you dead bug the  driver chips.  And don't forget, you still need 5 V for the driver chips.

The 328P and 2560 chips at 40 mA drive per pin don't quite meet the 488 spec of 48mA per pin to drive 16 devices,   But the SMD parts will source or sink a total of 200 mA.  With an Arduino all you need is ribbon cable and IDC 24 pin Centronics connectors and you can drive a reasonable number of devices simply by soldering the cable to the Arduino.

[H.O]

Just a quick note on the electrical specifications for the 328P.
The logic low input voltage for IEEE-488 (as for TTL) is max 0.4V. Looking at figure 29-8 in the datasheet for the 328P one can see that in order to meet that specification you can't sink more than ~17mA @25°C and if we're going by the "typical" low level voltage of 0.22V then it's more like 9mA.

[artag]

Although you're perfectly correct to say it won't drive the bus, I don't think of this as a multiple instrument driver (as I've said before). The STM32 will drive 6mA which is fine for 1 instrument.

Just give each instrument it's own USB interface.
If you want to drive a full bus (or even more than a couple of instruments I'd suggest using proper drivers.

At the price, I think this is a fair tradeoff for being unable to perform the few parallel operations that GPIB requires a bus for. It might not suit you

[MarkL]

Just a quick note on the electrical specifications for the 328P.
The logic low input voltage for IEEE-488 (as for TTL) is max 0.4V. Looking at figure 29-8 in the datasheet for the 328P one can see that in order to meet that specification you can't sink more than ~17mA @25°C and if we're going by the "typical" low level voltage of 0.22V then it's more like 9mA.

Actually, the IEEE-488 input spec is more lax than that.  From 488.1-2003, receiver sec 5.4.1:

    Low state: Input voltage ≤+ 0.8 V
    High state: Input voltage ≥ + 2.0 V

And while we're at it, driver sec 5.3.2:

    Low state: Output voltage (three-state or open collector drivers) < + 0.5 V at + 48 mA sink current
    The driver shall be capable of sinking 48 mA continuously
    High state: Output voltage (three-state) ≥ + 2.4 V at –5.2 mA

So, there's a lot of room in there for marginal implementations to drive less than a full bus of instruments.

[H.O]

Mark,
Thanks, I grabbed my numbers from here but I'll happily stand corrected. Perhaps they've changed the voltages in later versions of the standard meaning older instruments might not be that allowing - but I'm speculating.

I think this AR488 and the work that has gone in to it is great. My point was simply that the 328P, in reality, is a bit more limited than what was suggested in a previous message.

[rhb]

The bus specs reflect the technology of the time which was  TTL.  Don Lancaster wrote the classic work on it, "The TTL Cookbook" which is available for free on his website (tinaja.com) as a PDF.  He goes into considerable discussion of the way the chips work.  Reading the first couple of chapters is quite worth while. 

The GPIB specified voltages reflect the diode drops and noise margins needed for reliable operation of the TTL logic with which it was originally implemented.  Understanding the context of TTL logic imposed limitations will make the numbers in the IEEE-488 standard more meaningful.

The SMD 328P and 2560 packages have the same source and sink ratings of 200 mA.  The DIP 328P can only source 100 mA.   I don't yet know what the maximum demand per device for the bus is.  It depends upon the status of the control lines.  The data bus is 8 bits, so that's 24 mA for the selected device as unselected devices would have the data lines in high impedance state.  I'd expect the load for selecting a device to be the number of devices times the number of pins needed to retain control of the bus.  But I've not confirmed that yet.

Prior to wanting to automate a full cal of my bench I didn't have a lot of respect for the ATMEGA line.  But they fit in with a 5 V TTL world quite well and are cheap.  I've got  a lot of relays to drive, so I plan on using a pair of Mega2560s for the RF deck and another one to drive one or two  44421A boards from a 3497A for reading voltage references, etc.  That puts me at 4-6 devices per GPIB bus which should leave enough drive to power the 5 V relays which will control the 28 V RF relays and the 5 V 44421A relays.

Have Fun!
Reg

[MarkL]

Mark,
Thanks, I grabbed my numbers from here but I'll happily stand corrected. Perhaps they've changed the voltages in later versions of the standard meaning older instruments might not be that allowing - but I'm speculating.

I think this AR488 and the work that has gone in to it is great. My point was simply that the 328P, in reality, is a bit more limited than what was suggested in a previous message.

Well, it looks like www.interfacebus.com got it wrong in that table.  The input and output values they give amount to a negative noise margin.  I also have the 1987 version of IEEE 488 and the driver/receiver specs haven't changed.

Agreed on the 328P.  For microcontrollers with enough pins, there's also a possibility of paralleling output pins as long as they can be switched at the same time by putting them on the same I/O port.  The current sharing should be pretty good.  But for many microcontrollers the per chip maximums will start to get in the way.

EDIT:  One additional thought.... If there are enough microcontroller pins, the 48mA pulldown could probably be handled with a much cheaper driver like the ULN2003A or ULN2003LV.  The main reason not use the SN75161B/SN75162B sounds like it's cost (?).

[mlefe]

I have a (quick and dirty) first version of the port to the blue pill.
The tough (and ugliest) part of the code is the management of the registers, masks and so on, but I've tested the code on the side and looks like it works (it puts each pin in the right state).
The problem is that I can't have any communication with the 34401 nor the TDS744a that I have with me (and I know they're fine because they responded with Emanuel's code on an arduino).
Going deeper, I never get to the part where the devices are supposed to drive the NDAC low to start receiving, it's just like if they were not aware that the bus has a controller.
I'm almost certain that the problem is with my code but I can't figure out where I made the mistake
    --> do you know which lines should be driven (what state they should be in) to put the devices in "remote" mode?

[bitseeker]

This Bench Briefs article may be helpful. It describes the HP 59401A Bus System Analyzer, which is used to debug GPIB communications, and walks you through interacting with a device including which lines should be doing what and when.

http://www.hparchive.com/Bench_Briefs/HP-Bench-Briefs-1980-09-11.pdf

Especially take a look at the section, "Typical Data Exchange."

[JXL]

To put the device in remote mode, you have to turn on REN (logic 0).

[mlefe]

I think I've managed to kill the GPIB on my 34401a 
I have no response to an asserted REN (LOW) nor I get any information from the data pins when I put the device on address 31 (talk only).
I move to troubleshoot that... as soon as I fix it, I'll come back to the port: I'm sorry!

[rhb]

Maybe, *just* maybe mind you, 5 V logic will not work properly using 3.3 V logic levels.

5 V TTL logic high will source current at around 3.3 V ("The TTL Cookbook" p 10).  There are some diode drops between the rail and the output.  So if you knock 1.7 V off 3.3 V what do you get?