AR488 Arduino-based GPIB adapter

[vindoline]

rhb, I agree with the above. The AR488 works very well (for me!) as a GPIB-USB adapter. One already has to use another program to "talk" to it. I think the switching, logging, etc. belongs in that code. Compared to your stated expertise in various languages, I'm a complete beginner. However, I was able to hack together* a number of Python scripts running on a Raspberry Pi that handle all of my logging needs!

-Vindoline

* With lots of help from eevblog members! Thanks!

PS: the only modification of the AR488 code I had to make was increasing the maximum time-out. I use 8 seconds in my scripts as my ancient instruments are SLOW to respond. Most of the troubleshooting I've had to do with the GPIB logging has to do with timing issues.

[maxwell3e10]

In principle, the ability to reprogram an Arduino on the fly using the same USB port allows one to rethink the concept of a GPIB adapter. Instead of being just a dumb protocol translator, it can now take over some of the roles typically played by a program running on the computer. It maybe advantageous in some cases, since its a real-time processor. The down side is that a program like that could become less general. Still, its an interesting direction to explore. One example (not based on AR488 code) is  https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/
How to organize it logistically is an open question, anyone willing to invest their time can decide for themselves.

[rhb]

I can avoid a fork by simply maintaining a patch against the most recent version of AR488.  That's easy for me, but not necessarily comfortable for other people.  You need to be Unix literate and comfortable using patch and compiling, etc.  It's also complicated by the number of variants of Larry Wall's original patch program which are not quite compatible.

Because Prentice-Hall would not allow AST to post the Minix source on line, we had to do updates to the OS via patch(1).

My preference would be to allow enabling the relay control with "make -DRELAY".  It has been a very long time since I did any serious programming outside of a rather elaborate, mutliplatform build system I wrote on top of Gnu make.  That system has multiple layers which take care of various compiler and system dependencies.  So if it runs anything that even remotely resembles Unix and has Gnu make available it's completely transparent after I've configured the compiler and linker options.

So all I ever do is one of the following:

make
make test
make install
make DEBUG=1
make DEBUG=2

I can't see adding a 2nd Arduino to control the relays when the one handling the GPIB could do it.

[coromonadalix]

Something like a mega could do the task, tons of i/o to play with ?

[WaveyDipole]

So here's what I am thinking as add ons to the basic AR488 FW functionality for junior league voltnut use.

real time clock
temperature and humidity sensor (possibly more than one)
4-8 port input relay matrix
2-4 port output relay matrix
generation of sampling requests with AR488 (from a table of commands downloaded to the board)
CSV format output stream
option to drive a pair of 44421A relay boards for input and output switching (for TiN and Andreas wannabes

Any additional hardware would use additional control pins which on a UNO are already in very short supply. On a UNO/Nano, it may be possible to use a temperature and humidity sensor requiring one control pin each, but otherwise it would depend on how many control pins are required. The RTC, presumably something like a DS3231 Module uses the SDA and SCL pins, but these correspond to A4 and A5 on a UNO/Nano so that might also be a problem.

Generation of sampling requests using a table of commands should already be possible via the Macro feature, however downloading commands to the interface dynamically is presently resticted by the limited amount of dynamic runtime memory available on a UNO/Nano. EEPROM memory on these boards is even more limited so storing command sequences there is not viable. The "macro" feature was offered for the preset as a practical workaround as it stores command sequences in program memory. Both AR488 ++ and insturment commands can be used in the sequence and the can be exected at runtime with a single ++macro x command, where x is a number between 1 and 9. There is also a macro 0 which is the startup macro which can be used to initialise the board. I had updated the manual some time ago, but it seems that the online copy did not get updated. I have now rectified this and details of the macro command can now be found in the manual.

Creating a CSV output stream should not be that difficult.

I'd like to know if he'd accept conditional compilation of the features, and is there more functionality that would be desirable.

Conditional compiling of features as needed does seem to make sense. I had started to introduce some features on a "opt in" basis by removing the comment flag before certain #define statements, partly because not everything can be used at the same time due to overlapping pin requirements (on a UNO or NANO). Bluetooth and WiFi (still working on WiFi) are an example of this. They cannot be run concurrently on a UNO/Nano as there is only one UART. I hadn't got to the point of exploring compiler flags though.

Something like a mega could do the task, tons of i/o to play with ?

Yes, all the above are good reasons to explore the Mega. This would allow rather more flexibility to develop additional features. It may be that the UNO/NANO version would remain the "basic" implementation, while the Mega would be the "advanced" version. It really depends what can be squeezed in to the lower end boards. I actually  purchased a Mega a couple of months ago to play with, but am still working on the WiFi feature so haven't got around to that stage yet. It sounds like I should probably focus on this next and get it done sooner rather than later?

[rhb]

Yes, all the above are good reasons to explore the Mega. This would allow rather more flexibility to develop additional features. It may be that the UNO/NANO version would remain the "basic" implementation, while the Mega would be the "advanced" version. It really depends what can be squeezed in to the lower end boards. I actually  purchased a Mega a couple of months ago to play with, but am still working on the WiFi feature so haven't got around to that stage yet. It sounds like I should probably focus on this next and get it done sooner rather than later?

With Chinese Uno  copies selling for ~$3 US I think the Uno/Nano should remain the basic implementation and that if someone wants additional features beyond time, temperature and humidity they should use a Mega. 

GPIB cables have become expensive and hard to get.  They are also very bulky.  I could never connect my bench using those.  However, I could put  a 328p based interface on each instrument, connect them to a USB hub and connect that to the computer.  I can cable from a single Arduino using custom made IDC connector cables and that is what makes sense for a Mega based unit driving relays.

I bought a 37203A GPIB extender to use the case for running one or more of the 44421A boards.  AS I am a world class example of Attention Deficit Disorder nothing much has happened on that except for using the board to test my desoldering tools and salvaging the TTL chips. The problem was severely exacerbated by a *major* TEA binge.  At present I have an 8753B/85046A, 8566B, 16500 & Tek 11801 parked in my living room because I don't have anywhere else to put them yet.  And that is only about half the gear I bought post 37203A time.

For two months prior to the Cal Club kit arriving all my attention had been on mechanical engineering related to rebuilding a $525 Chinese mini-lathe into a high precision instrument maker's lathe. All of which has taken my attention away from playing jazz guitar.  so Murphy says that my friend who is a professional session player will show up to play when I'm so out of practice I can't quite keep up.

I'm putting the Cal Club kit in the post Monday at which time I'll load AR488 on a Mega, print the source code,  put it in a notebook and start studying.  I'm having my prostate removed on Thursday, so I will have a couple of weeks during which my mobility is rather restricted.  So a good time to work on adding enhancements to AR488.  Starting with learning the current source code.

My post was intended to help define what I should do, not what WaveyDipole should do.  That's your decision.  I have a lot of experience working with very large legacy code bases.  One of the things you learn quickly is to make your work fit in with the existing work as seamlessly as possible.

The purpose of my post was to see if there were other things I should be thinking about where to fit them when I study the source code. One thing that occurred to me yesterday was to have a multiline LCD panel option that would provide a scrolling display of what the interface was doing.

[coromonadalix]

@rhb

The " lcb tft touch "backpack for the mega would be an awesome addition ...  your sucess may depend on how you'll add thoses functions vs all the i/o's available,  maybe some i2c expanders, i2c adc / dac

Dallas one wire temperature sensors ?

I have an Teensy 3.2 who's sitting duck in a drawer, maybe i could use its horse power ??

[bitseeker]

The purpose of my post was to see if there were other things I should be thinking about where to fit them when I study the source code. One thing that occurred to me yesterday was to have a multiline LCD panel option that would provide a scrolling display of what the interface was doing.

Yes, depending on screen space and layout, in addition to the interface's state, the status of the bus (data and control lines) would be useful.

As a separate project idea, I had thought about making something similar to the HP 59401A, but more user friendly.

[rhb]

@coromonadalix & @bitseeker

Thanks.  I'll look into those.  I have a slew of MCU dev boards to choose from in addition to the Arduinos.  I need to make some mockups of a front panel using the standard HP dimensions for that size instrument and study the 44421A schematic to see how many GPIOs I need to drive it.

I'm likely to wind up with a couple of versions.  For the lab self cal system I'd prefer to use N connectors because they're much more robust.

It appears I could just fit a pair of 4421A relay boards in the 37203A case with the terminal blocks sticking out the front.  Or I could use a single relay board and get 20 banana jack pairs, but neither of those would leave much room for a screen.

So what is cheap and uses the 8560 size HP enclosure?  Or is a standard blank 19" rack enclosure a cheaper choice?

Off to look at the listings for TFT LCD Arduino Mega backpacks ;-)

Have Fun!
Reg

[maxwell3e10]

I had updated the manual some time ago, but it seems that the online copy did not get updated. I have now rectified this and details of the macro command can now be found in the manual.

Thanks for updating the manual. It looks like it is missing the ++repeat feature, which is very handy.
The bluetooth capabilities look really cool too, I should play with it sometime. I wonder if one can steal power from rarely used GPIB lines and use a small boost converter to generate 5V for power and make the adapter completely wireless.

[WaveyDipole]

Thanks for updating the manual. It looks like it is missing the ++repeat feature, which is very handy.

Thanks for spotting that! The omission has now been corrected.

The bluetooth capabilities look really cool too, I should play with it sometime. I wonder if one can steal power from rarely used GPIB lines and use a small boost converter to generate 5V for power and make the adapter completely wireless.

The IEEE488 connector does not provide any power, only signal pins and ground.

[WaveyDipole]

The AR488 is now available for the MEGA2560.

The code has now been ported and should hopefully provide a basis for future expansion projects such as the work proposed by rhb. Since the MEGA2560 has a different pin layout to the UNO and NANO, the original AR488.ino sketch will NOT work with this board. A new revised sketch, AR488-mega.ini has now been uploaded and is available for use on the MEGA2560. With the exception of low level pin and interrupt handling, the code is essentially the same and works the same as the UNO/NANO version.

Having looked at various shield boards and displays, it became evident that it was not possible to accommodate every conceivable option. Most shields plug into the single row of connectors either side of the board, but the more advanced displays (e.g. touchscreens) use the 'digital' connector at the end of the board. It seemed unlikely that the use of shields would be required, so reservation of the 'digital' connector for displays was given priority. In addition, implementation of the data bus does not require the use of PCINT's so the use of analog pins A0-A7 as digital pins for the data bus was preferred over using pins A8-A15. As  result, pins 2-5, 13 (LED), analog pins A8 to A15, as well as the entire "digital" connector (pins 22 to 53) at the end of the board are not used by the sketch and remain available for expansion.

Please be aware that pins 16 and 17, corresponding to TXD2 and RXD2 (the Serial2 port) are used by the sketch to handle GPIB control signals and cannot be used for serial communication. They were chosen because they map to port H along with pins 6-9. Having all GPIB control pins assigned to the same port makes things much easier to to program. It seems unlikely that all 4 serial ports would be required and serial ports 0, 1 and 3 remain available for use. I considered this to be a reasonable compromise to allow the maximum possible potential for expansion, nevertheless, I am open to suggestion regarding the pin assignment.

There is still some work to be done on the sketch in connection with the management of serial ports, for example, Serial1 will be used for Bluetooth communication and WiFi passthough on the MEGA2560. However, that aside, the sketch is functional and did seem to work fine with my MEGA2560 board and both the Solatron and Keithley DMMs. Admittedly I haven't tested device mode yet.

The documentation has been updated to include the MEGA2560 and wiring diagrams have been added for both the UNO and the MEGA2560.

Although Mega boards cost a little more than UNO or NANO, there are some MEGA2560 'mini' boards that are not actually that much more expensive:
https://www.ebay.co.uk/itm/Mini-MEGA-2560-Pro-Micro-USB-CH340G-ATMEGA2560-16AU-For-Mega-2560-R3-Arduino-UK/192781866481?epid=13032626770

[maxwell3e10]

I wonder if one can steal power from rarely used GPIB lines and use a small boost converter to generate 5V for power and make the adapter completely wireless.

The IEEE488 connector does not provide any power, just signal pins and ground.

Yes, that's what makes me wonder about it, otherwise it would not be interesting I think I have a plan for how to do it, we'll see if it works.

[coromonadalix]

The "supply trick" was on rs232 to hold some "unused lines" at high, and with small signal diodes harvest some supply current


Thank WaveyDipole for the mega conversion

[maxwell3e10]

Yes, I think all the lines on GPIB are used some of the time, but if one connects all control lines to a boost converter with Schottky diodes and a big capacitor, it may work OK.

[bitseeker]

The AR488 is now available for the MEGA2560.

Very cool! It'll be exciting to see what kinds of things this upgrade enables. I suppose this could also enable more than one GPIB bus with the additional digital pins.

[rhb]

I had not seen those mini Mega256 boards before.  At under $8 US I'm going to get some for the final build and use the larger units I have just for dev work.  I'm not a big fan of the MCU chip, but the prices make them very compelling.

Thanks for doing the port.  That will let me focus on various RTC clocks, T&H sensors and driving things like the 44421A boards.

Have Fun!
Reg

Who is finally destressing now that the Cal Club kit is in the post.

[WaveyDipole]

Thanks for doing the port.  That will let me focus on various RTC clocks, T&H sensors and driving things like the 44421A boards.

You're welcome. It seemed an opportune time to get the MEGA2560 port to a working level at least on par with the existing UNO/NANO version. As mentioned, there is still a bit more work to do so there will be further updates at some point. In the meantime, it is encouraging to see someone wanting to further enhance the usefulness of this project and I look forward to seeing how your ideas progress.

[theHWcave]

Powering from GPIB might just be possible. I found accidentally in my Arduino Nano based GPIB-to-USB converter, that the ATmega328pb was “powered” through its IO lines when the USB power was off but the GPIB was left on.
In that stage, VCC was 2.2V coming via IO lines and termination resistors from the GPIB. The ATMega did not like that at all and corrupted the flash memory every time that happened. Had to reload the program to get the converter working again. In the end I enabled Brown-Out detection (BOD), set to 4.3V to hold the chip in reset until 5V from the USB was detected, and that fixed the problem. You can see the story on this here https://youtu.be/DAS1KVU_FaA 

So in this case, I did not want the feed from GPIB but using a circuit that would combine through diodes the voltage of some of the GPIB lines, buffer it in a large cap and boost it if necessary to 3.3V or so, may be able to do the trick if you use low power WiFi (or BlueTooth). 

[bitseeker]

Yes, there's a little power available on the lines, but they're not intended to be for powering devices. Signal integrity could be compromised. At worst, you might burn out the output drivers of instruments on the bus.

I found some electrical info on this page: http://www.interfacebus.com/Design_Connector_GPIB.html. See the table, "IEEE-STD-488 I/O Characteristics."

[Brumby]

I can see myself getting interested here.....

[bitseeker]

Come on in, the water's fine.

[maxwell3e10]

I ordered all the parts to try the self-power trick. But since I am unwilling to pay more than $1 for each, it will take a month for them to get here. If one looks at a GPIB driver chip like SN75161 it should be possible to pull about 10 mA from each line. Arduino + Bluetooth might draw together anywhere from 20 to 70 mA, depending on how careful one is. So it might work, but will be close.

[WaveyDipole]

Powering from GPIB might just be possible. I found accidentally in my Arduino Nano based GPIB-to-USB converter, that the ATmega328pb was “powered” through its IO lines when the USB power was off but the GPIB was left on.

Dave covers that parasitic power phenomenon here:
https://www.eevblog.com/forum/blog/eevblog-831-power-a-micro-with-no-power-pin!/

It is for this reason that I included a paragraph in the manual to advise that when multiple devices are connected to the GPIB bus, that the Arduino should be removed from the bus when it is not powered. In a one-to-one situation, the issue does not arise.

Your comment makes an interesting point about the brownout detection (BOD) setting though. I checked my boards (2 X UNO and 1 x MEGA2560) and found that the extended fuse is set to FD on all three. My NANO failed some time ago so I can't report on that particular board. Being set to FD means that the first three bits are set to 101 and therefore that BOD is set to BODLEVEL1 with a threshold of 2.7v. Since I had made no previous attempt to change this fuse on any board, I can reasonably assume this to be the default setting for both UNO with 328p and MEGA2560 boards.

It is curious, then, that on your board this was set to FF. Is this something specific to boards using the newer 328pb processor perhaps? Did the manufacturer not program the board properly? Or did the fuse get inadvertently changed somehow? I might be useful to know whether other boards with this newer 328pb processor have their extended fuse also set to FF?

In the meantime, it is helpful to know that if the fuse is disabled then flash memory could get corrupted, so thanks for pointing that out. I will be adding this information in the AR488 manual.

[OH2LIY]

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