AR488 Arduino-based GPIB adapter

[coromonadalix]

it was bought here,  called  gpibsub      2 of them based on 32u4  avr

They do work up to a point,  not blaming the seller

They dont mount properly the 34410a meter i have,  and  keysight sorftware doesn't see it,  but it work in usb  mode

It's the  given pinout    schematic posted earlier

i have a hard time to figure out how to give it  some basic  leonardo pinout  or sparkfun pro-micro   pin naming / id's   used in arduino IDE

there is 3 pins  who give me some headache,  may have to do some hardware mods ...

[Nx-1997]

There is nothing wrong with xyphro's UsbGpib (https://github.com/xyphro/UsbGpib) adapter. All you need with this adapter is to install R&S Visa Software (https://www.rohde-schwarz.com/ca/applications/r-s-visa-application-note_56280-148812.html), nothing else. Also, the solution to the meter's initial error is shown on his GitHub page.

This adapter is a lot faster then the AR488 adapter, in terms of data transfer speed. Much better then even the commercial adapters.

[coromonadalix]

Ok  thks a lot  Nx-1997,    not hijacking this thread

Works fine, use R&S  configurator  and use R&S  Visa as preferred

For the "old" Agilent / Keysight DMM,  i had to install  old  I/O librairies to make it work ??

Keysight DMM  works !!!

Ill continue to read this thread,  i have ordered  ARTAG  pcb's for the sparkfun pro micro  and see ....  Gpib plugs received

[caiser01]

Ok  thks a lot  Nx-1997,    not hijacking this thread

Works fine, use R&S  configurator  and use R&S  Visa as preferred

For the "old" Agilent / Keysight DMM,  i had to install  old  I/O librairies to make it work ??

Keysight DMM  works !!!

Ill continue to read this thread,  i have ordered  ARTAG  pcb's for the sparkfun pro micro  and see ....  Gpib plugs received

If you're going to ARTAG's boards, make sure you have the correct board layout uncommented in AR488_Config.h:

Code: [Select]

/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
  /*** Board/layout selection ***/
  #define AR488_MEGA32U4_MICRO  // Artag's design for Micro board
  //#define AR488_MEGA32U4_LR3  // Leonardo R3 (same pin layout as Uno)

The default changed between 0.49.14 and 0.51.09, and when I recently upgraded the firmware on my ARTAG boards everything stopped working. Had a minor freak out before I realized it was this change in AR488_Config.h causing it but at least it was an easy fix!

[earlish]

There is nothing wrong with xyphro's UsbGpib (https://github.com/xyphro/UsbGpib) adapter. All you need with this adapter is to install R&S Visa Software (https://www.rohde-schwarz.com/ca/applications/r-s-visa-application-note_56280-148812.html), nothing else. Also, the solution to the meter's initial error is shown on his GitHub page.

This adapter is a lot faster then the AR488 adapter, in terms of data transfer speed. Much better then even the commercial adapters.

I can also confirm that xyphro's UsbGpib works great with the 34401A and Nx-1997's software. Thanks so much it's really awesome.

[ON7CH]

Hello to all,

I am using the AR488 Pro-Mini with an FTDI cable.

With a terminal program (Termite...) I can control a RACAL 1991 counter and the HP53131A counter.

If I want to use EZGPIB, this does not work.
However, my AR488 Pro-Mini has been positively recognized by the EZGPIB program. CTS=OK

Can someone advise me to make my AR488 Pro-Mini work with EZGPIB.

Thanks in advance.

Guido

[ON7CH]

Here some extra information regarding the problem with EZGPIB and the AR488_Pro-Mini.

Below the Debug Messages of the two different configurations.
- EZGPIB with Prologix & RACAL Counter
- EZGPIB with AR488 ProMini & RACAL Counter

It is as if the GPIB-commands are well received by the RACAL counter but the measurements responses are not readback by the AR488.

Guido

[bingo600]

So it begins, I have found my old project bag with connectors and buffers from saner and healthier times, not let's assemble the first board from Jay, a beautiful menstrual red, mine are puke green  .
Still boards available for DE !!!

Cheers,
DC1MC

I just got some neatly assembled boards from DC1MC 
They were made for nothing but "parts cost", and a small token "for the Cat".

Thank you for that ... Now i have backed up my HP3478A

Edit: Also Thank you to JDB for making the buffered PCB.

And that sparked my GPIB interest again ... I just installed linux-gpib on my Raspi3, for my Agilent USB adapter.
And did an alternae 3478a calram backup there.

/Bingo

[DC1MC]

@bingo600 - thanks for the nice words and support.

@world there are sill a couple more available, if I somehow manage to get over my crazy sickness I'll be able to finish them and hopefully find them a nice home, unfortunately the prognosis isn't that good  :'(, especially if they intubate me (no, not Covid, unfortunately some other shite can terminate you). Well, if this happens there will be lots of Ferengi food on Bus/sell.. while I will embrace my new "in the cloud(s)" status  .

One word of advice, check you vitamin D and B12, egal if the health insurance doesn't pay for the tests, pay yourself, best money spend, my levels were not fully zero, but kind of the lowest measurable limit. At this levels every stupid viral cold can frak you for good. And why were so demented low, well because yours truly had months and months of drinking Cola Zero instead of anything, because A) I don't like coffee and B) I'm a giant idiot 


Cheers,
DC1MC

[bingo600]

if I somehow manage to get over my crazy sickness.

I wish you a quick recovery 

Ps: I take my Vitamins every morning, SWMBO will make sure of it.

/Bingo

[Tj138waterboy]

Is it possible to bodge in a multiplexer or temp humidity sensor or are all needed pins taken/unable to be interrupted?

[WaveyDipole]

I have just pushed an update which cleans up some of the code and includes additional fixes some recently reported issues. I have also removed dependence on the DEVNULL library by importing its code into the AR488 project.

Is it possible to bodge in a multiplexer or temp humidity sensor or are all needed pins taken/unable to be interrupted?

Quite some time ago, someone produced a layout that freed up the SDA/SCL pins which allowed a sensor to be attached. I will have have a trawl through the thread to see whether I can dig out this information. I think it required one of the pins to be sacrificed, but can't remember for sure and, if so, which one at this point.

I had also been working on including MCP32017/8 or MCP32S17/8 chips into the project with the idea being to run the GPIB bus from the MCP chip while leaving the other pins available for various sensors. I had some success, getting this to work primarily with the MCP23S17, but unfortunately while doing some more work on this recently, both of the chips got fried and I am not sure why yet. I suspect they maybe can't handle a full load of 16 GPIB bus signals or else I made some stupid wiring mistake, or perhaps I was fortunate for a while and they require buffering resistors or something. Whatever the case, I will need to order some more chips to pursue this further.

[coromonadalix]

noob here

Having theses ic's on the gpib board(s) even controlled separately,  you would need some new gpib commands / set ??   since they would run on a "declared / identified" Windows Linux Mac gpib peripheral

Would it still work on IVI, Ni Visa, Keysight   etc ....  drivers ?

No ?  Yes ? 

Don't want to be rude nor offensive, but now   It would be a new kind of peripheral and a new code to implement and manage  

I don't call this a gpib adapter anymore ? or call it an AR488 ??

[WaveyDipole]

My aim was for the project to operate exactly the same as the current AR488. These chips communicate with the Arduino via the I2C (MCP23017, MCP23018) or SPI (MCP23S17, MCP23S18) bus and they simply extend the number of available GPIO pins. There would be no need for separate or additional commands. I intended their inclusion to be completely optional and enabled/disabled in the AR488_Config.cfg file, much the same as is currently the case with the SN7516x buffers. Ironically, it might actually be cheaper now to just buy a Mega2560 board which is why after my two test chips got toasted, I was ready to abandon the idea. If there is no usage case, then it is probably not worthwhile spending more money, time and effort developing that option.

[dietert1]

I guess with an I2C port expander GPIB transfers will be rather slow. Better use a MCU with more pins.
Recently i made a proto board using all 16 GPIOB ports of a bluepill module and there were still enough ports left for I2C, SPI, one UART and a LED. GPIB transfer speed was 300 KBytes/second at 80 MHz CPU clock, including debouncing/synchronizing incoming GPIB control signals and data.
Next one may be a 64-pin MCU with MC3446 buffers or the like, with two separate 16-bit ports for sending and receiving GPIB signals. It can support tracing GPIB activity while acting as system controller.

Regards, Dieter

Edit: SPI is for a ADS1256 mezzanine that is needed for precision temperature and for a DIY relay scanner.

[WaveyDipole]

Dieter, yes that was also my concern with I2C. I got it working but it was never stable and I suspect that might be partly the reason why. On the other hand, the SPI version worked very well until the chip failed....

I find it interesting that you got BluePill to work. Which BluePill board did you use? I had a couple of STM32F103C8 boards here but I could not get them to function, not even with blink example. I could get the board to present a CDC USB port when programmed with a specific bootloader and I could program it with an ST-Link but the board just did not seem to do anything else. For example, the LED would not blink when the blink sketch was uploaded and with the bootloader uploaded, the board would not respond to programming via USB as it was supposed to. After a lot or trying I finally gave up on it. It might be that the examples I had were fake but the consensus after seeking help was that they were not working properly so I gave up on them. I have been considering using the Pico board instead.

Incidentally, I have now added a number of links into the opening post for the various AR488 projects discussed within the thread.

[dietert1]

Yes the two bluepill modules i got did not work either, so i ordered two STM32L433CCT6 to replace the bad MCU. This worked well and i could use a cheap STLink programmer and CubeMX. USB worked out of the box and without pulling in a realtime OS. For the GPIB  test i had to mod the bluepill once more:
- "free" PB2 (L433 doesn't need Boot1)
- wire 1K5 USB pullup to PA8 in order to automate USB re-enumeration at boot time (USB "pretreatment")
There are 16x 2k7 pull-ups to 3.3V on the bottom.

Regards, Dieter

[coromonadalix]

ok  it would need  more horse power  ....   teensy ?

[dietert1]

Teensy has a VFPv5 with double support, so it may even replace a RPi, except with fast GPIB. For a test i wired up a GPIB connector to a NUCLEO-H743ZI board without bus buffers and it works well.
The STM32L433 i mentioned is 5V tolerant on most pins. With Teensy one can use a bus interface with level translation. For example the bus receivers in MC3446 won't output more than 3.3 V with a 5 KOhm pulldown.

Regards, Dieter

[WaveyDipole]

Yes the two bluepill modules i got did not work either, so i ordered two STM32L433CCT6 to replace the bad MCU. This worked well and i could use a cheap STLink programmer and CubeMX. USB worked out of the box and without pulling in a realtime OS. For the GPIB  test i had to mod the bluepill once more:
- "free" PB2 (L433 doesn't need Boot1)
- wire 1K5 USB pullup to PA8 in order to automate USB re-enumeration at boot time (USB "pretreatment")
There are 16x 2k7 pull-ups to 3.3V on the bottom.

Regards, Dieter

Ah, so it wasn't just me having problems with the cheap STM32F103C8 then! I spent probably 3 full days on trying to get it the basics to work it and it was driving me crazy! I forgot to mention that I did do the resistor mod (to A12 on these) for USB enumeration, upgraded the library in the IDE and tried different programming methods and bootloaders including the older Maple and newer HID bootloaders. I might just get a Nucleo-32 to play with. I have been trying to work out whether it is 5V tolerant which you seem to have answered in your last post. I had wondered the same for BlackPill SMT32F401. The datasheets do not seem to make this clear.

[coromonadalix]

same here, had same problems on the "blue pill"    bought the "corrected" boards  ... worked fine

recently had problems with a pro micro, to find they had another bootloader type (32u4 from sparkfun) now works fine ...

And some arduino mini who had another mega 328 type got refunded, nothing would work in IDE

[dietert1]

5V tolerance is specified in the pinout table in the datasheet. Pins marked as "FT_something" are 5V tolerant in GPIO mode. There is a legend above that table.
By the way: Digikey has 20x Nucleo-L433 on stock for US$20 each. It's a Nucleo-64, so twice the price for twice the pins..

Regards, Dieter

[serg-el]

Quite some time ago, someone produced a layout that freed up the SDA/SCL pins which allowed a sensor to be attached.

It was me.
The BME and BMP sensors have been connected and have been verified to work.
The board is used by RobotDyn UNO R3 ATmega328P-AU

[rockstedy40]

Hello everyone,

First I want to thank all the very talented people who’ve created so many versions of the 488 adapters.  Almost too many to choose from.  Especially want to thank WaveyDipole for all his work on the software and support he’s given, and  Jay_Diddy_B for his board design that I’ve chosen to use.

I have been concentrating on building the buffered version by Jay_Diddy_B, shown in reply 862.  I’m waiting on parts and so started to get going on the AR488 software.  I’d like to get confirmation on the changes I need to make on the Config.h file.  The numbers at the beginning of the lines below are the line numbers of the unmodified config.h file.

45   //#define AR488_UNO  // Commented this line out since a NANO board is being used.
46   #define AR488_NANO  // Uncommented this line since a NANO board is being used.

158 #define SN7516X  // Uncommented this line since the design uses buffers.
 
160  #define SN7516X_TE 6  //Jay_Diddy_B SD Rev 2 in Reply 848, pg34, shows SN75160-1 and 61-1 (TE) going to D6.  So uncommented this line.

161  #define SN7516X_DC 13 // Jay_Diddy_B SD Rev 2 in Reply 848, pg34, shows SN75161-11 (DC) going to J1 for selection of either D3 or D13.  But D3 is also used for REN so use pin 13.  Thus uncommented this line.

162 //  #define SN7516X_SC 12 // Jay_Diddy_B SD Rev 2 in Reply 848, pg34, shows SN75161-14 (EOI) connected to D12.  Can't find an "SC" on the schematic, so leave commented out.

163  // ONLYA board  // Since I'm not using the ONLYA board, I think the following two lines should be commented out.
164 //  #define SN7516X_TE 13
165 //  #define SN7516X_DC 5

186 thru 197 deal with interrupts.  Since I’m using a NANO, should the interrupt section be uncommened?

205-216 deal with dip switches, which I don’t have.  Should line 205 (#define DIP_SWITCH) be commented out?

Thanks in advance
Bob

[WaveyDipole]

186 thru 197 deal with interrupts.  Since I’m using a NANO, should the interrupt section be uncommened?

205-216 deal with dip switches, which I don’t have.  Should line 205 (#define DIP_SWITCH) be commented out?

The interrupts section should remain commented out. It is no longer needed.

The lines relating to DIP switches can be commented out. It was an idea quite a long time ago to have the GPIB address made configurable with DIP switches, but these definitions are not implemented. I will remove them in the next release.