GPIB interface (IEEE488)

[amspire]

Current is the one thing I am not concerned about. The 50ma rating drives 14 devices at high speed on a 20 meter cable. The Arduino is usually driving 1 device on 0 metres of cable at low speed  and it can comfortably drive 20ma. In practice, my Arduino is using less then 20ma in total  when talking to a gpib device.

I will hook up the  oscilloscope and logic analyser and compare the Arduino to the specs. I am going to assume that the Arduino is closely connected to at least one device with the proper termination. See what can be done.  Going to proper driver chips does mean the addition of 200ma of current, a PCB and ICs that cost more then the Arduino clone.

My Arduino is working reliably on the 3 devices I have on hand, so my only concern is "is it safe?".

[bitseeker]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

[bitseeker]

Here is the words from the CC nonderivative license:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

It is OK to freely distribute unmodified CC NoDerivative-licensed source code. Not sure about a diff file that can modify this source. Any opinions?

IANAL, but it seems that patches are not addressed. The license is about the original code. My understanding of the spirit of the license is that it's to be used when the author doesn't want his name and/or software associated with derivatives over which he has no influence nor control. Whether or not distributing the original as-is along with diffs keeps with the spirit of the license, I suppose it does to the extent that it disconnects the association somewhat. More separation could be achieved by not distributing the original, but documenting in the diff where to get the original to which the diff can be applied.

Of course, one could still contact the author to propose adding the changes to the code base. If he pulls them in, it'd be less hassle.

[amspire]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

Just had a quick look at the IEEE488 specs. The maximum  voltage out from any pin should be 3.7V no load. Now it should be possible to make the Arduino outputs behave like open collector outputs as Jim (jimmc) described. If the Arduino high outputs are switched to just the >20K pullup, then the maximum high voltage you would get on a closely connected (ie the adapter plugged into the instrument directly) would be 3.5V.

Looks like the recievers should be rated to accept 5.5V or less, so the current implementation of the outputs is not a disaster - just way out of specs for IEEE488.

Anyone could add the 3k+6K2 resistors on every output if they want - just in case they need to use a cable, but I do not want to.

[amspire]

Here is the words from the CC nonderivative license:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

It is OK to freely distribute unmodified CC NoDerivative-licensed source code. Not sure about a diff file that can modify this source. Any opinions?

IANAL, but it seems that patches are not addressed. The license is about the original code. My understanding of the spirit of the license is that it's to be used when the author doesn't want his name and/or software associated with derivatives over which he has no influence nor control. Whether or not distributing the original as-is along with diffs keeps with the spirit of the license, I suppose it does to the extent that it disconnects the association somewhat. More separation could be achieved by not distributing the original, but documenting in the diff where to get the original to which the diff can be applied.

Of course, one could still contact the author to propose adding the changes to the code base. If he pulls them in, it'd be less hassle.

I would contact Emanuele. I have already donated some money to him for his efforts. The diff only works if you have exactly the right version of the source, but it would be possible to host the source at one place, and distribute the diff separately.

The author is talking about a V6.2 coming out, but it does look like changes are needed right now.

There is a potential copyright issue with diffs in that they will contain a number of lines from the copyright code. It would be possible to come up with a solution that just replaced every changed line and inserted new lines and the differential update file would have no copyright code from the original. Take a bit of scripting to implement it.

[JXL]

How about just posting the changes/edits as a reply to Emanuele's blog?  Instead of dealing with the license issues, I did just that with handling the SRQ feature.  That way the source and changes are in the "same place".  Just my $.02

[amspire]

How about just posting the changes/edits as a reply to Emanuele's blog?  Instead of dealing with the license issues, I did just that with handling the SRQ feature.  That way the source and changes are in the "same place".  Just my $.02

Thank you for that SQL code - I will take a look.

Could do it that way, but you were just doing a small addition. Not sure how you would post a major change in the forum. Just for example, if someone wanted to convert it from a dedicated controller mode to controller and device mode, it would probably mean big changes to Emanuele's code. You would need to post the entire revised source code on the forum, but you cannot - that would break the license.

[macboy]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

Just had a quick look at the IEEE488 specs. The maximum  voltage out from any pin should be 3.7V no load. Now it should be possible to make the Arduino outputs behave like open collector outputs as Jim (jimmc) described. If the Arduino high outputs are switched to just the >20K pullup, then the maximum high voltage you would get on a closely connected (ie the adapter plugged into the instrument directly) would be 3.5V.

Looks like the recievers should be rated to accept 5.5V or less, so the current implementation of the outputs is not a disaster - just way out of specs for IEEE488.

Anyone could add the 3k+6K2 resistors on every output if they want - just in case they need to use a cable, but I do not want to.

One absolutely must emulate open collector outputs for a GPIB interface. The 5 control lines in particular are not compatible with active-high driven mode of operation. Trying to drive these high would result in similar problems as a I2C device trying to drive lines high. It doesn't work properly because it contradicts the protocol. For example, a I2C master that drives the clock high may work with many devices, but will suddenly fail to work with a slave device that uses clock stretching.

On most microcontrollers, including the Arduino's Atmega328P, you can emulate OC outputs by setting and leaving the output state to 0 (low), then toggling the pin between output (drive low) and input (float high).

[amspire]

One absolutely must emulate open collector outputs for a GPIB interface. The 5 control lines in particular are not compatible with active-high driven mode of operation. Trying to drive these high would result in similar problems as a I2C device trying to drive lines high. It doesn't work properly because it contradicts the protocol. For example, a I2C master that drives the clock high may work with many devices, but will suddenly fail to work with a slave device that uses clock stretching.

On most microcontrollers, including the Arduino's Atmega328P, you can emulate OC outputs by setting and leaving the output state to 0 (low), then toggling the pin between output (drive low) and input (float high).

You are right that we should emulate the OC output, but the consequences of driving high are not as bad as you would think. Any time the lines are driven high, no other device should be pulling low - that is the theory, anyway. Also, GPIB inputs are rated to handle 5V, but under 4V is better.

The reasons for going OC with all the lines are that it makes the Arduino immune from damage if another device is pulling low at the wrong time (maybe a device misbehaves on startup or shutdown), and also that speed is not the issue. The serial port in at 115200 baud which is just over 10,000 bytes per second. That is the maximum speed you can get out of this device, so active pullups are definitely not needed for speed. The code actually has liberal 10, 20 and 30 microsecond delays everywhere, so I think Emanuele decided that with about 100uS per byte maximum speed, he could be generous with delays for settling time without affecting speed much.

I am definitely going to test OC-type outputs, and I also have also hooked a logic analyser up. I can see a few odd things that probably will not affect it working, but just do not look right. Overall though, the traces look excellent.

Also I have taken the baud rate up to the maximum for a 16MHz Atmega328 of 1000000 baud on my Arduino and it works! There could be some hope of speeding this up. To get any GPIB speed improvement, I have to start reducing the built-in delays.

Richard

[amspire]

Just ordered a bunch of Arduino Pro Micro boards (9 for A$25.56) using the ATMega 32U4 chip. The different port allocation will definitely need a change to the UNO GPIB code, but the huge thing is the USB is on chip, so it actually doesn't care what serial speed you connect at - it always runs faster USB speed then the Arduino + serial chip combo can manage. The normal Aliexpress price is about A$4.

http://www.apcc.tk/news/arduino-pro-micro

[amspire]

The 24 pin male PCB GPIB tend to be hard to locate (hard to know what to search for), so here are some links. If anyone has a cheaper source (Aliexpress, etc) please post them:

http://au.mouser.com/ProductDetail/NorComp/112-024-113R001
http://au.mouser.com/ProductDetail/TE-Connectivity-AMP/5552741-1
http://www.digikey.com/products/en?keywords=1024RMA-ND
http://www.digikey.com/products/en?keywords=A31843-ND

There is a Fuyconn 57RR series 24 pin connector, but I do not know a source.
http://www.fuyconn.com/products_detail1/productId=474.html

[bitseeker]

Thanks for those links, amspire. The connectors are 24-pin, Centronics type. DigiKey seems to have quite a variety of them, though some are obsolete. Here's a list of the right-angle, through-hole versions in both genders that are listed as active:

http://www.digikey.com/products/en/connectors-interconnects/d-shaped-connectors-centronics/438?k=&pkeyword=&pv1989=0&FV=114016f%2C1140215%2C160001d%2C1680002%2Cffe001b6&mnonly=0&newproducts=0&ColumnSort=1000011&page=1&quantity=1&ptm=0&fid=0&pageSize=25

[amspire]

Did a quick test with the pins changed to OC (open collector) mode and as expected, the adapter still works fine. There is no need for any active pull-up. Fall time is not an issue - something like 10ns. Rise time was 0.3us and if I add termination resistors on the adapter, this will drop to 0.15us. This will be completely adequate.

Richard

[amspire]

Just attached an example of the Arduion Uno GPIB with a quick mod to make it OC outputs - none of the outputs are driven high any more. The time taken to set the data lines is simply that my OC mod is setting each data line seperately.

This is an *IDN? request of an HP 33120A AWG.

If you want to understand it, the Talker puts the byte on the data lines. The names might be confusing - the bus uses negative logic so Low = True. The Talker waits until all the Listeners have set the NRFD (Not Ready for Data) High to indicate everyone is ready, and then it pulls the DAV (data available) low to tell the Listeners that a new byte is available. As soon as this happens, the Listeners pull the NRFD low again to indicate they are processing the data, and set NDAC high when the data has been accepted. When all the Listeners have accepted the data, the Talker sets the DAV high again and starts loading the next byte to the Data lines.

A nice thing about this bus is there are very few parts of the protocol with critical timing. In general, the whole conversation between Talkers and Listeners can slow down to whatever speed the slowest device can manage. With Emanuele's code, the adapter only runs at about 1/100th of the old IEEE488 maximum speed, and 1/800th of National Instrument's High Speed modification of the standard. It sounds bad but most GPIB instruments cannot achieve full speed and do not need to have much speed.

The *idn? request to the 33120A:


The reply back from the 33120A:

[jimmc]

Ebay UK source of  connectors http://www.ebay.co.uk/itm/Centronics-Plugs-Sockets-PCB-Ribbon-Cable-R-A-Mount-14-50-Way-EB67-1-piece-/391507935311?var=&hash=item5b27b1004f:m:mL3rRc-lMiIx-rItIkYt3Ig.
I used the straight PCB connector (with wires) which made the adaptor small enough to plug straight onto the test gear.

Re logic levels, extract from MC3447 attached, typical output high is 3.5v.
As I said in my first post, no guarantees but it has worked for several people so far and is by far the cheapest solution so far.
Now if only doktor pyta would modify his code...

Jim

[amspire]

The MC3447 is half the supply current of the SN75160/75161 chips, but it seems to be very hard to get. The few stockists seem to be charging a lot of money.

Interestingly, looking at some photos of 2005/2007 Prologix boards, it looks like they are directly connecting ATMEGA ports straight out to the GPIB connector - no driver chips. I do not have photos of their latest products but they quote 100mA maximum supply current. Given the current needed to power the bus, they probably are still not using any GPIB bus drivers.



The IEEE488.1 spec says the drivers have to sink 48mA at 0.5V. Looks like the 2007 Prologix used Atmega16A family chips that can manage about 24mA out at 0.5V from the ports. The Atmega328P can manage about 18mA at 0.5V.

As I mentioned, the 48mA only matters if you are driving 14 devices on 20 meters of cable. If you are driving 3 devices on 2 meters of cable, 18mA would be overkill. The equation for any of the output ports is basically 1.6mA maximum per listening device plus whatever extra you need to drive the cable capacitance.

Edit: The Prologix was discussed in this thread: https://www.eevblog.com/forum/chat/prologix-gpib-usb-controller/
Looks like it might be an ATmega164P chip.

[WaveyDipole]

I have just found a UK source of an in-line plug. There is no mention of IEEE488 or GPIB so it doesn't come up in searches. RS are currently not charging for postage.
http://uk.rs-online.com/web/p/general-purpose-rectangular-connectors/2391207/

[amspire]

I have a couple of the PCB connectors from Mouser on order along with some mini Arduino boards coming from China. Mouser were as cheap as anywhere else.

I am particularly keen to try out the Leonardo-style mini boards with the superior serial protocol - up to 2,500,000 baud regardless of the port baud rate settings. Probably will not do any more till I get them, but I was thinking about using classes to implement a GPIB state machine that exactly follows the IEEE488.1 spec that is specified in terms of state machines. It is the only way I can think to exactly follow the standard without a massive amount of work. Could easily be slower then Emanuele's version, but it might work.

It will need some changes - to be able to run in the non-controller mode, the ATN and EOI have to be implemented using interrupts to get the needed speed. You would think the SRQ should be an interrupt, but there is no need for it to react quickly. The SRQ just waits there till the software gets around to handling it.

If I succeed, I will release the code under the MIT license. I really like that license - "do what you like, but don't blame me".

Emanuele's version is really excellent as is. He has really put a lot of great work into this project. It will probably handle most needs and it works just as well if you turn all outputs to Open Collector type outputs. For the moment, I have put my Duemilanove in a cardboard box and that will be my USB to GPIB converter till I get the new hardware.

Richard

[bitseeker]

Wow, 2.5M baud. I have not worked with those boards before. Should be interesting.

"do what you like, but don't blame me"

Sounds like a good license to me!

Oh, and it looks like GPIB interface prices on eBay are recovering.

[Johnny10]

So I should have bought two ?

[bitseeker]

Maybe. Reselling the second could've paid for the first. C'est la vie. It's like stocks. You just never know what'll happen.

Meanwhile, if you need another interface, you could give the Arduino project a try.

[WaveyDipole]

I have completed building my GPIB interface. I was able to source the 24 way plug from RS and a 2m length of cable by purchasing an old parallel printer cable from a market stall. Finally the Arduino board came from eBay. The total cost was 12.47GBP.

I have tried it today and unfortunately it doesn't work for some reason. Having confirmed that the address is set to the deafult of 23 and connecting up the interface cable I used PUTTY on Windows to make the connection manually. I do get the reposnse from the ++ver command:

Code: [Select]

ARDUINO GPIB firmware by E. Girlando Version 6.1
However, I am not 'seeing' the HP3478A. For example, I get nothing on the meter when I try to run:

Code: [Select]

OUTPUT 723;"D2Hello"
Enabling ++verbose mode I get:

Code: [Select]

> gpibWrite: timeout waiting NDAC
set_comm_cntx: gpib write failed @1
gpibTalk: set_comm-cntx failed.

>

So I checked all of the wiring to ensure that each wire is connected to the correct Arduino output. I checked continuity on all wires. I then connected a Logic Analyzer to the DAV, NFRD and NDAC lines to observe the handshake and got absolutely nothing. Thinking that my Arduino board was faulty, I then unplugged from the instrument and uploaded a basic LED blink sketch. By changing the pin number and re-uploading the sketch, I was able to confirm that each pin was being pulled up and down and the board is therefore working correctly.

I am therefore at a loss to explain why I am getting no output with Emanuel's code either with the instrument connected or not.

[JXL]

Verify REN is connected to signal ground.
And set the listener's address with "++addr <listener address>"

[plesa]

Send to Arduino GPIB adapter this commands ++addr [address]  and  ++auto
If it will still not respond try to send to instrument "END ALWAYS"

[WaveyDipole]

Thanks for the replies . In had, in the meantime, enabled debug mode in the code so as to get more information about what was happening and also realized that the interface was coded to send to address 2 by default.

As suggested I set the address to 23 (the default instrument address) using the ++addr command. On sending a command, the logic analyzer was now showing some activity and I briefly saw the instrument indicate 'LISTEN' on the display, which seemed to confirm that it was indeed now receiving the data being sent to it. However it still did not seem to be obeying any commands that I was sending. I tried ++auto and sending 'END ALWAYS', as well as the previous OUTPUT 723;"D2HELLO" but to no avail.

However, at this point, the SRQ and REN lines were still not connected to GND. I had purposely left them n/c as I was contemplating connecting them to channels on the Arduino. Emanuel Girlando's documentation does say that they should be connected to GND and this was also pointed out by JXL. Since they evidently should not be left floating, I decided to complete what I was planning and connected GPIB10 and GPIB17 to channels 2 and 3 of the Arduino board. I then modified the code to add a #define for them and set them LOW. This way I could experiment with them later and would be ready (channel mapping notwithstanding) for any future code update that may implement these features. After compiling and uploading the code I tested it again and this time interface worked! 

So I can confirm that the problem was twofold: the GPIB device address needed to be set to 23 using ++addr and the SRQ and REN lines should not have been left floating.

Hopefully I can now start experimenting with the instruments features. I will have to make a donation to Emanuel for making the code available.