open source GPIB adapter

[dorkshoei]

I saw the recent thread here on NI adapter authenticity.   I'd been pondering buying something so it was timely.

I also found this old thread here inquiring about about open source adapters.

One of the comments on the thread was "the real cards are GPIB32 and VISa compliant. something none of the homebrews does."

I stumbled on this project which claims to be VISA compliant https://github.com/xyphro/UsbGpib

Has anyone tried it or are there any recommended projects to build since the 2012 thread?  Or is one of the commercial devices (if authentic) still the way to go?  Note I'm asking for a functional opinion not time vs money as that's very subjective.

I like the right angled compact design of the above githib design.

[Nx-1997]

I have built and successfully tested the xyphro’s UsbGpib adapter. The good news is that it is compatible with all popular vendor visa software, that means that it works with NI Visa, Keysight Visa, and Roden&Schwarz Visa. I personally prefer the R&S Visa as its only 59 MB in size and works perfectly but no python visa support. Only the NI Visa software is supported by the Python’s PyVisa library. The adapter is also very fast in terms of data transfer speed, faster than Keysight 82357B adapter and AR488 adapter.

Now the bad news is that the adapter shows up as a USB device and not as a GPIB device that means compatibility is not as great compared to a traditional GPIB adapter. As in Image 1, if a software does not search for USB devices, then xyphro’s UsbGpib adapter will not be detected as shown in image 2. You would have to include the “USB” search string, shown in image 3, for the software to detect the adapter, as shown in image 4. Also you can only connect 1 instrument per adapter and build costs are higher compared to AR488 adapter.

[nctnico]

I have built and successfully tested the xyphro’s UsbGpib adapter. The good news is that it is compatible with all popular vendor visa software, that means that it works with NI Visa, Keysight Visa, and Roden&Schwarz Visa. I personally prefer the R&D Visa as its only 59 MB in size and works perfectly but no python visa support. Only the NI Visa software is supported by the Python’s PyVisa library.

Fortunately that is not true. Pyvisa also works with PyVISA-Py which is a Python based implementation of a Visa library which prevents you having to install the dreadfull NI Visa software. 

[Nx-1997]

Nice, I hasn't aware of this library (https://github.com/pyvisa/pyvisa-py). I will test it out when I get time.

[dorkshoei]

Now the bad news is that the adapter shows up as a USB device and not as a GPIB device that means compatibility is not as great compared to a traditional GPIB adapter.

Do any of the open source adapters show up as a GPIB adapter?   Is there an alternative you recommend?

[Nx-1997]

Now the bad news is that the adapter shows up as a USB device and not as a GPIB device that means compatibility is not as great compared to a traditional GPIB adapter.

Do any of the open source adapters show up as a GPIB adapter?   Is there an alternative you recommend?

I personally don't know of any open source GPIB adapters that show up as GPIB devices. Your best bet would be to get a used NI GPIB-USB-HS adapter or a pci/pcie gpib adapter. If you plan on creating your own scripts/software then the xyphro’s UsbGpib adapter will work well.

[dorkshoei]

Now the bad news is that the adapter shows up as a USB device and not as a GPIB device that means compatibility is not as great compared to a traditional GPIB adapter.

Do any of the open source adapters show up as a GPIB adapter?   Is there an alternative you recommend?

I personally don't know of any open source GPIB adapters that show up as GPIB devices. Your best bet would be to get a used NI GPIB-USB-HS adapter or a pci/pcie gpib adapter. If you plan on creating your own scripts/software then the xyphro’s UsbGpib adapter will work well.

Thanks.  So what were your build costs?  I thought I saw $14 mentioned on xyphro's github page.    This AR488 setup doesn't seem like it would be that much cheaper.    I also dislike micro-usb, it's not very durable.     I prefer USB-B that xyphro uses.     Also like that he has the case design ready for printing.

[Nx-1997]

For AR488 pro micro adapter:
Arduino pro micro 1pcs - $7 CAD with shipping
Centronics Connectors 5pcs - $13 CAD with shipping
PCB 5pcs (optional) - $16 CAD with shipping

For xyphro’s UsbGpib:
ATMEGA32U4RC-AU-ND 5pcs – $37.65 CAD Digikey
SMD Components - $8 CAD Digikey
Centronics Connectors 5pcs - $13 CAD with shipping
PCB 5pcs - $16 CAD with shipping

Cost in USD will be lower.
Xyphro’s cost of 14$ USD per adapter is probably true.

I got the connectors from here: https://www.aliexpress.com/item/32795413098.html?spm=2114.13010708.0.0.7bff4c4d5RM2NJ

[dorkshoei]

Nx-1997  thank you for your help. Much appreciated.

If anyone in US has a spare xyphro PCB they don't want please send me a PM. They are thin enough that they should be shippable taped to a piece of cardboard at the 1oz letter rate.

[jjoonathan]

Nice, I hasn't aware of this library (https://github.com/pyvisa/pyvisa-py). I will test it out when I get time.

My setup is GPIB ----AD007---> Ethernet -> pyvisa-py. I've used it for about 10kloc of scripting at this point, and I love it. No NI drivers, no Keysight drivers, no nonsense, just python and jupyter and it just works.

EDIT: and no USB drivers either, and no serial libraries. No Device Manager, no INF files, no udev files, no FTDI drivers. Really.

[dorkshoei]

My setup is GPIB ----AD007---> Ethernet -> pyvisa-py.

Are there any open source ethernet designs?  Or are they all USB?   Plenty of cheap SoC's now with Ethernet support.

[jjoonathan]

I don't think so, but I'd love to be wrong about that!

[giovannirat]

You mean something like

https://www.eevblog.com/forum/metrology/yaugi-4-gpib-ethernet-poe-adapter/msg3280916/#msg3280916

?

[dorkshoei]

For xyphro’s UsbGpib:
ATMEGA32U4RC-AU-ND 5pcs – $37.65 CAD Digikey

ATMEGA32U4 seems pretty solidly discontinued. Octopart shows 0 in stock at authorized distributors.

Utsource.com who are IME about as reputable as you can get with Chinese chip sellers shows their stock is all "used".  All the third parties on their site claim new which I assume is BS along with theChinese eBay/aliexpress sellers.

[robert.rozee]

ATMEGA32U4 seems pretty solidly discontinued. Octopart shows 0 in stock at authorized distributors.

Utsource.com who are IME about as reputable as you can get with Chinese chip sellers shows their stock is all "used".  All the third parties on their site claim new which I assume is BS along with theChinese eBay/aliexpress sellers.

see:
https://www.microchip.com/en-us/product/ATmega32U4
ATmega32U4
Status: In Production.

the part is, however, mostly out of stock. like a great many devices from a variety of manufacturers, more supplies are not likely to be seen until late 2022.


cheers,
rob   :-)

[Kean]

Almost 15k pcs (TQFP) expected to be available for direct purchase in March (I don't put much trust in their stock levels or ETA dates though)
https://www.microchipdirect.com/product/ATMEGA32U4-AUR

[dorkshoei]

For xyphro’s UsbGpib:
ATMEGA32U4RC-AU-ND 5pcs – $37.65 CAD Digikey

ATMEGA32U4 seems pretty solidly discontinued. Octopart shows 0 in stock at authorized distributors.

Utsource.com who are IME about as reputable as you can get with Chinese chip sellers shows their stock is all "used".  All the third parties on their site claim new which I assume is BS along with theChinese eBay/aliexpress sellers.

I'm also pretty sure ATMEGA32U4RC above is not the correct part.     Looking at the data sheet the RC has an internal oscillator and isn't compatible with an external.   The UsbGpib uses an external 16mhz crystal.

You need the ATMEGA32U4-AU which of course is not in stock.    I may get used ones from utsource,  I've had fairly good luck with them before.

[maxwell3e10]

I am wondering if the xyphro's code can be modified slightly to use standard Arduino Pro Micro. A few of the pin assignments need to be changed and the bootloader is different. But otherwise one can just get a complete Arduino board and wire it up to GPIB connector.

[Nx-1997]

For xyphro’s UsbGpib:
ATMEGA32U4RC-AU-ND 5pcs – $37.65 CAD Digikey

ATMEGA32U4 seems pretty solidly discontinued. Octopart shows 0 in stock at authorized distributors.

Utsource.com who are IME about as reputable as you can get with Chinese chip sellers shows their stock is all "used".  All the third parties on their site claim new which I assume is BS along with theChinese eBay/aliexpress sellers.

I'm also pretty sure ATMEGA32U4RC above is not the correct part.     Looking at the data sheet the RC has an internal oscillator and isn't compatible with an external.   The UsbGpib uses an external 16mhz crystal.

You need the ATMEGA32U4-AU which of course is not in stock.    I may get used ones from utsource,  I've had fairly good luck with them before.

The ATMEGA32U4RC and ATMEGA32U4 are the same, only difference is the fuse configuration. I bought the ATMEGA32U4RC because the ATMEGA32U4 was out of stock. You will have to set the fuses anyway when flashing the bootloader.

[dorkshoei]

The ATMEGA32U4RC and ATMEGA32U4 are the same, only difference is the fuse configuration. I bought the ATMEGA32U4RC because the ATMEGA32U4 was out of stock. You will have to set the fuses anyway when flashing the bootloader.

Perhaps I'm just not understanding the datasheet or it's confusingly worded.

6.2.1 Default Clock Source ATmega16U4 and ATmega32U4 The device is shipped with Low Power Crystal Oscillator (8.0MHz-16MHz) enabled and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock with an 8 MHz crystal. See Table 28-5 on page 348 for an overview of the default Clock Selection Fuse setting.

6.2.2 Default Clock Source ATmega16U4RC and ATmega32U4RC The device is shipped with Calibrated Internal RC oscillator (8.0MHz) enabled and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock. See Table 28-5 on page 348 for an overview of the default Clock Selection Fuse setting.

[Venturi962]

The ATmega32U4RC will work fine, that's what I'm using in the ones I built up.

I did have to slow down the bitclock when flashing the bootloader (note the -B 10 at the end) YMMV:

avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m avrdude -c usbasp -p m32u4 -U flash:w:BootLoader.hex -B 10

[artag]

ATMEGA32U4 seems pretty solidly discontinued. Octopart shows 0 in stock at authorized distributors.

Still plenty in the channel in the form of pro micro arduinos. I've only glanced at xyphro's code, but I think it could be fairly easily modified to work with the pcb I did for the AR488. Probably with a slight loss of speed, as the pinouts are likely to be less optimised for the code.

Of course, that wouldn't give the layout and usb connector you prefer. The best solution to that is probably to 3d-print a case that gives extra support to the micro-usb connector - I think there's one already in the AR488 thread.

As for ethernet versions : yes, that would be great (although USB is quite convenient in providing power). One way to do it would be via an ethernet-equipped pi or Beaglebone linked to a bunch of USB adapters. Direct connection to ethernet would be faster, but most instruments are fairly slow. Also, all the single board computers with ethernet that I know of (beaglebone, arduino, raspberry pi and teensy 4.1) have 3.3V I/O so you'd need to use the proper buffers. This might seem no great disadvantage or even an improvement but a single bus also means you can't run data transfers in parallel as you can with multiple USB ports.

[dorkshoei]

Still plenty in the channel in the form of pro micro arduinos.

Indeed. It makes me wonder whether the Chinese "new" stock available for direct purchase is then actually authentic, vs used/remark.   The fact that utsource (who are one of the few honest sellers) has marked all their stock as "used" makes me suspicious of the rest.

[artag]

Quite possibly. However, I've bought chinese ARduino micros recently and they've all worked OK. So even if they're clones or pulls, they do seem to be functional at least IME.

[dorkshoei]

I ordered from utsource, they listed two used lots,  each several thousand.     Of course it turns out they had zero.   

I guess I'm waiting till they come back into stock.   I'm in no rush so that's fine.   Spent the last couple of days 3D printing some enclosures for them ;-)

[dorkshoei]

Almost 15k pcs (TQFP) expected to be available for direct purchase in March (I don't put much trust in their stock levels or ETA dates though)
https://www.microchipdirect.com/product/ATMEGA32U4-AUR

DigiKey now has some stock https://www.digikey.com/en/products/detail/ATMEGA32U4-AUR/ATMEGA32U4-AURCT-ND/3440960

Which is good as some of the brokers have started to take the piss https://www.win-source.net/hot-sales-and-eol-components-atmega32u4-au.html

[PioB]

As the TQFP Atmega32U4 is unavailable(but there are some qfn around, hope they'll be left when I submit my next order ) , I have _started_ copying @xyphros https://github.com/xyphro/UsbGpib schematic into Kicad and started with a layout. I think I need to redo it and put the MCU on the back side as the routing of the GPIB connector is a mess....



I attached the KiCAD 6 project, will try and get around to improving it soon, but not tonight anymore 

[PioB]

Oh i just saw, I forgot to connect the VBus Pin of the MCU to 5 V...  I quickly rectified that, not that the routing is any more beautiful now...
File added
USB-GPIB adapter copied from xyphro's schematic, for the QFN Atmega32U4, a 6x3.5 mm Crystal and Wuerth MicroUSB.
If anyone has any hints for improving the layout, I'm all ears

I added the step files for the USB connector and the GPIB connector to the zip, they need to be added to the footprint, as I have saved and linked them locally in my 3d model directory...

[Venturi962]

Thanks for the head start, reworked VBus, caps and some signal lines.

Edit: Made some more updates. 

Hardware Notes:

• Schematic has 100nF Caps for the Crystal, original has 22pF
  
• Switched to more common Crystal size
• Prefer through-hole pin headers as opposed to SMD

[Gribo]

You might want to add some ESD protection diodes on the USB lines.
The QFN pad could use a symmetrical via arrangement. You don't want voids when soldering it.
Edit: The VBus trace should be thicker.

[Venturi962]

Incorporated those updates.  Included 4 Channel ESD protection (2 Channel part is Out of Stock but should be pin compatible).

[PioB]

So I had an earlier Version of the PCB with VBUS connected made at a Chinese board house and am trying to program it now... As I don't have a "real" programmer I am using my Arduino Uno on which I have installed scratch monkey (stk500) https://github.com/microtherion/ScratchMonkey/tree/master/doc and which I have used before to successfully program Atmel MCUs.
Unfortunately this time I am not lucky, command line from https://github.com/xyphro/UsbGpib:

Code: [Select]

sudo avrdude -c stk500 -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m avrdude -c stk500 -p m32u4 -U flash:w:BootLoader.hex -P /dev/ttyACM0
 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x3f
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:FB, H:99, L:52)

avrdude done.  Thank you.

Does anyone have any hint how to modify the command line to burn the bootloader?
(atmega32u4rc-mu, should be configurable to use the external xtal which IIUC would be taken care of by the fuses?)

[Venturi962]

Try setting bitclock in the avrdude command, for example add '-B 10' to the end.

[PioB]

Thanks, that still yields the same answer unfortunately
.

[mankan]

You have not written the bootloader, just set the fuse bits. Divide the first line into two commands, both starting with avrdude.

[PioB]

Thank you very much mankan and Venturi962. I bought a avr jtag ice mkII (clone?) and that seems to make life a bit easier (without capacitor and it seems to work more reliably than the arduino stk500... Separating the two commands seems to have brought me a step further. The firmware can be written, but apparently I cannot program the fuses. "avrdude: verification error; content mismatch" So the board is not recognized as a usb mass storage device. (I also do not see any 16 MHz Signal on the two xtal pins, not sure if this is relevant....)

Code: [Select]

$avrdude -c jtag2isp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m
:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x3f
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:FB, H:99, L:52)

avrdude done.  Thank you.




$ sudo avrdude -c jtag2isp -p m32u4  -U flash:w:BootLoader.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "BootLoader.hex"
avrdude: input file BootLoader.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against BootLoader.hex:
avrdude: load data flash data from input file BootLoader.hex:
avrdude: input file BootLoader.hex auto detected as Intel Hex
avrdude: input file BootLoader.hex contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 32768 bytes of flash verified

avrdude: safemode: Fuses OK (E:FB, H:99, L:52)

avrdude done.  Thank you.


Reading back the fuses/other info yields the following:

Code: [Select]

avrdude -c jtag2isp -P usb -p m32u4 -n -v -B22

avrdude: Version 6.3, compiled on Jul 21 2021 at 00:00:00
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude/avrdude.conf"
         User configuration file is "/home/baettig/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : jtag2isp
         Setting bit clk period        : 22.0
avrdude: usbdev_open(): Found JTAGICE mkII, serno: 00B000004F4F
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              0
S_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              1
Serial number:                   00:b0:00:00:4f:4f
Device ID:                       JTAGICEmkII
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : JTAGMKII_ISP
         Description     : Atmel JTAG ICE mkII in ISP mode
         Vtarget         : 5.1 V
         SCK period      : 23.12 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FB

avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FB
avrdude: safemode: Fuses OK (E:FB, H:99, L:52)

avrdude done.  Thank you.



[maxwell3e10]

It would be so much easier if the firmware just run on standard Arduino Pro Micro. No programmers and no PCB needed. Xyphro doesn't like the idea, but it wouldn't be hard to change, I think. 

[Venturi962]

It looks like you're getting stuck on the lock bit - can you write any fuse?  I think you only need to set the Low and High fuses in this case, Lock and Extended aren't strictly needed.

avrdude -c jtag2isp -p m32u4 -e -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m

[simba15]

It would be so much easier if the firmware just run on standard Arduino Pro Micro. No programmers and no PCB needed. Xyphro doesn't like the idea, but it wouldn't be hard to change, I think.

I would highly agree, with an Arduino Almost any one could make this, The current setup requires external tools and introduces extra challenges. Its a great project but if I really want to build one these are the truth.

[PioB]

Another step further...
so the fuse setting ran, thank you Venturi962! and the programming too.

Two of the fuses seem to be correct the lock one is untouched.
I re-plugged it in and it appeared as a storage device
$lsusb
Bus 003 Device 019: ID 03eb:2045 Atmel Corp. LUFA Mass Storage Demo Application


I then copied the test and measurement bin to the drive and verified if it copied ok.

$cp TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN

$md5sum TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN
bb6785db41417e20e522b72fcbcfba61  TestAndMeasurement.bin
bb6785db41417e20e522b72fcbcfba61  /run/media/baettig/GPIBUSBBOOT/FLASH.BIN

So I unplugged it and plugged it in one more time, now it should not be visible until it is connected to the GPIB on a TM device...
It reappeared as a drive ...
Unplugging and plugging it into my E3633 power supply (configured as a GPIB device) still doesn't make it change itself to a GPIB interface...

according to the manual on github
"USB enumeration
You might be surprised initially, that the device does not show up in your device manager (or lsusb), when you connect only the USB side. This is a feature, not a bug (really!). Only, if a GPIB device is connected, you can see the device on your PC too."

(I just checked on github and  seem to have run into an issue that someone else is at, too: https://github.com/xyphro/UsbGpib/issues/11 unfortunately without resolve so far...)

I'd be grateful for any hints.

[Venturi962]

Can you try programming the extended fuse as well?  May have misspoke when I said it wasn't needed.

avrdude -c jtag2isp -p m32u4 -e Uefuse:w:0xcb:m

Once you have Flash.bin on the device a power cycle via USB shouldn't show a Drive anymore, but the LED should start flashing to let you know it flashed.

[PioB]

Thank you very much! Another step closer.

ok, the process so far:

avrdude -c jtag2isp -p m32u4 -e -Uefuse:w:0xcb:m
avrdude -c jtag2isp -p m32u4 -e -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m
avrdude -c jtag2isp -p m32u4  -U flash:w:BootLoader.hex
 -> yields
  avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)
unplug, replug
cp TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN
  verify with md5sum, umount, unplug

replug it into the usb port
Hmm and it still is recognized as a LUFA drive.
  Bus 003 Device 027: ID 03eb:2045 Atmel Corp. LUFA Mass Storage Demo Application
unplug, plug into the E3633A and still LUFA
If I understand correctly, the fuses should now all be correct. (Windows also sees it as a storage device, connected to the power supply)

[Venturi962]

Can you try copying the TestAndMeasurement.bin on a Windows Machine instead of Linux?  I did this on Windows (power cycling and not unmounting / ejecting) and I wonder if the unmount on Linux is causing problems. 

[PioB]

Hi Venturi962

Thank you very much for helping me, it's now being recognized under Windows as UsbGpib in the device manager if the power supply is connected. Linux now announces
Bus 001 Device 004: ID 03eb:2065 Atmel Corp. LUFA Test and Measurement Demo Application

So tomorrow I'll try and get pyvisa working and finding the instrument on the gpib bus.

I'll report back once *IDN? returns something

Thank you very much!

[PioB]

Another step further... under linux I installed pyvisa, linux-gpib, pyvisa-py. Now I am trying to get to the instrument but:

Code: [Select]

python
Python 3.10.2 (main, Jan 17 2022, 00:00:00) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvisa
>>> rm = pyvisa.ResourceManager()
>>> print(rm.list_resources())
()
>>> pyvisa.log_to_screen()
>>> print(rm.list_resources())
2022-02-25 18:14:39,047 - pyvisa - WARNING - Found a device whose serial number cannot be read. The partial VISA resource name is: USB0::1003::8293::???::0::INSTR
()
(and other errors, /dev/usbtmc0 is in no group, just root has rw permissions, at the moment I have to chmod 666 every time I reboot/unplug it to access the usb-gpib adapter as a regular user)

Under windows, I haven't installed any VISA so far, is there something smaller than the (multi)GB Keysight or NI Visa?

but apparently the USB-GPIB can see the power supply:


Step by step..

[Venturi962]

On Linux, try this: https://techoverflow.net/2019/08/09/how-to-fix-pyvisa-found-a-device-whose-serial-number-cannot-be-read-the-partial-visa-resource-name-is-usb0-0instr/ - I recall some issues like this on a Raspberry Pi,  I could run Python scripts as Root to get around the issue temporarily.

On Windows, I think you can also use PyVisa + PyVisa-Py if you don't want to use other VISA solutions (personally I use the Keysight one).

Linux-gpib isn't needed as this is considered a USB Resource and not a GPIB one.

[PioB]

Thank you very much Venturi962, I owe you one!
And I will refer back to the forum here next time I upgrade fedora... Everything works and I got an answer from my power supply!
Both modules I built work and I can talk to the power supply!

 

python
Python 3.10.2 (main, Jan 17 2022, 00:00:00) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvisa
>>> rm = pyvisa.ResourceManager()
>>> print(rm.list_resources())

('USB0::1003::8293::HEWLETT-PACKARD_E3633A_0_1.4-5.0-1.0::0::INSTR',)
>>> my_instrument = rm.open_resource('USB0::1003::8293::HEWLETT-PACKARD_E3633A_0_1.4-5.0-1.0::0::INSTR')
>>> print(my_instrument.query('*IDN?'))
HEWLETT-PACKARD,E3633A,0,1.4-5.0-1.0




Thanks a lot!

[dazz1]

Hi
I saw early discussion on this thread about availability of MCUs.
element14 shows both:
ATMEGA32U4-AU, part number 1748525  and,
ATMEGA32U4-MU, part number 2425127

are in stock.

Which is the easiest package to hand solder? 

[dazz1]

Thanks for the head start, reworked VBus, caps and some signal lines.

Edit: Made some more updates. 

Hardware Notes:

• Schematic has 100nF Caps for the Crystal, original has 22pF
  
• Switched to more common Crystal size
• Prefer through-hole pin headers as opposed to SMD

* usb_gpib_2022_02_06C.zip (1880.68 kB - downloaded 47 times.)

Hi
Is this the latest design version?

[dazz1]

Hi
I have ordered Xyphro PCB design, then I found this thread.  Hmmmm.  I have changed course and now intend to build the Ventura variant. 

I like the Ventura design a lot and I am looking at making some minor tweaks.
I'd prefer the old USB B connector because it is a lot more robust than a micro.  1st option was to allow either to be used on one PCB design, but my initial assessment is that I don't think it is viable without increasing the PCB size.   Given that a small increase in the PCB size would have zero cost consequences, that option is still worth considering. 

The newish type C USB connector looks to be more robust than the micro without the bulk of the B version.   Maybe this version:  https://nz.element14.com/molex/217175-0001/usb-conn-2-0-type-c-rcpt-6pos/dp/3702928?ost=2171750001.   A C-type connector might be the best choice for a new design.

Also considering using a dual colour LED driven half by pin 39.  Something like this https://www.farnell.com/datasheets/1676973.pdf.  This would remain compatible with xyphro code but allow for some future enhancements to LED indications. 

I haven't used KiCAD before so modifying an existing design would be a good learning exercise.

 

[dreamcat4]

couple of things:

a) if there is something new and usedul in that zip file code... it should be up into github. and properly versioned / rebased. and or optionally pr (depends if worth the bother)

b) we can already see here (see pic) in the network graph. was things added in somebody else's fork in january. for example the usb-c connector is amongst one of those changes

https://github.com/xyphro/UsbGpib/network

although personally i am more interested in using an arduino micro board. and then vero boarding it together to the gpib connector. to see how that turns out... got the updated version of the arduino micro with usb-c on it.

[dazz1]

Hi
It is not my zip file and although I have a github account, I don't really know how it works.  I didn't know about the really useful network feature, so I didn't know what nipo had done. 

I think there are three improvements worth doing on the nipo fork:
1.  add anti-static protection on the usb lines.
2.  add a bi-colour LED which can display 3 distinct colours that can communicate quite a bit of information. 
3. a better 3D enclosure.

[dazz1]

Hi
I have used this project as an excuse to learn KiCad.
I have gathered together the good ideas of others to create the bestest and most marvelous version of the schematic and PCB for the USB-GPIB adapter.
"My" design is a combination of the best features I see in other designs, plus a couple of features I have dreamed up.

The fruits of my effforts can be found here:
https://github.com/dazz100/UsbGpib/tree/USB-GPIB-Dazz/HW/Dazz

The changes made include:

• Adding ESD protection,
• Adding USB-C connector,
• Used hand solder friendly larger 0603 sized components,
• Added 2x options for mounting bi-colour LEDs,
• Added 2x 3mm mounting holes to anchor the enclosure to the PCB.
• Used a rectilinear shaped PCB to make it easier to use on stiff connectors.

The USB-B connector is chunky and robust but relatively large.
The USB-micro may be too fragile for knocking around in the lab.
The USB-C seems to be the Goldilocks choice.

The larger 0603 sized components will make it easier for the visually challenged to hand solder this project.

I think the addition of a second LED can be used to convey useful status info to a user, much like the LEDs on an ethernet socket.
I have added a LED to a spare output of the MCU.  The original software will continue to drive one LED.  The software will need to be modified to enable driving the second LED.
I have found that there is no standard orientation of the rear panel connection.   Readily available bi-colour SMD LEDs point upwards.    I have added the option of fitting right angle LEDs on the end of the PCB (opposite the USB).  Regardless of orientation, these should always be accessible to see.

Centronics connectors can be stiff to insert/remove.  The addition of two mounting holes will allow the enclosure to be anchored to the adapter with 3mm screws.
For similar reasons, I have used a rectilinear PCB to make it easier to include finger grips in the design of the enclosure.  The PCB has been slightly extended so there is some bare PCB that can fit into a slot within the enclosure to further anchor the enclosure to the PCB.

The form factor of a "standard" GPIB cable assembly is side entry.   This is similar to the form factor of my PCB/enclosure design. I see no advantage in a stepped shape of the PCB.

I decided very early not to make any hardware changes (eg. pin allocations) that would require code changes.  This includes the bi-colour LEDs which will run as a single LED mode on the current software version.  So although this version is only similar in hardware design, it is not essential to modify the software.

I haven't yet decided whether the enclosure will be a one-piece "cup" or a two-piece clam shell. 


I think this is a really good project and the incremental development by others has only improved the outcome.    I have three items of old test equipment with a GPIB bus so this adapter will be a way of increasing their usefulness.

I am seeking feedback on the schematic and pcb designs.  Have I got it right??   Is there a feature missing??  Any feedback would be welcomed.

[coromonadalix]

personally love the usb-c variant

My 2 cent comment would have been to provide some pads for say rgb or 2 color led  3mm or 5 mm led (with their full lenght pins) being put on the side of the pcb  if you 3d print some enclosure, the smt led would not be visible ? and with an hole / windows 

it is not always easy to see them


and i would have used standard straight pins for the programming connector, the right angled one give me chills to solder and i would say they could break easier than going thru the pcb ??

annnd they are easier to source, any long straight header pins can do ...


thks

[dazz1]

Hi
Thanks for you feedback.

The header is already straight pin thru holes. See the attached 3D model.

The advantage of SMD LEDs is that I can slide the pcb into a one piece enclosure without having to worry about snagging LEDs that stick up through holes.
To get around the problem of poor visibility of the LEDs, I was thinking of adding  diffuse semi-transparent inserts in the enclosure.    A simple way to make inserts would be to take standard LEDs and drill out the leads and diode leaving just a coloured shell.  This could then be glued into the enclosure with no attachment to the PCB or smd LEDs.

I could add thru-hole led pads, but the LEDs would dictate a two piece clam shell enclosure in their current position.   I haven't designed the enclosure yet, but I am heading towards a one piece design that the adapter slides into.

I could fit the leaded LEDs along the left edge of the PCB (as drawn).  The LEDs could then slide into holes in the enclosure.  The advantage of leaded LEDs is that they are available everywhere.

[dazz1]

My 2 cent comment would have been to provide some pads for say rgb or 2 color led  3mm or 5 mm led ...

PCB mount indicators like this one:

https://us.rs-online.com/product/dialight/550-5207f/70081710/

look like good candidates.

I have had a quick tour through the code, and it looks like it would not be too difficult to add LED status for various actions.   

[coromonadalix]

a last comment  loll

would it be better to use a 10 pin variant of the jtag   ISP  instead of the 6 pin

because many many adapters / programmers come with the 10 pins and you have to do some battle  to get the 10 to 6 pin converter or find programmers in the 6 pin variants

happened to me and was frustrating  ...

another 2 cents


willing to buy assembled board ??  or you'll provide the bare board  gerbers  etc

[dazz1]

Hi
I have a programmer on order from Aliexpress, complete with the necessary adapter. 
The extra 4 pins of a 10 pin header would take up quite a bit of real-estate on the pcb.

[dazz1]

willing to buy assembled board ??  or you'll provide the bare board  gerbers  etc

I will buy the bare board and assemble myself for my own use.
I hadn't considered making/selling them.

Most parts come in 5's but I only need 3 adapters.   I expect to have at least 2 spare boards plus parts left over.
This is a very niche item.

[dreamcat4]

Hi
I have a programmer on order from Aliexpress, complete with the necessary adapter. 
The extra 4 pins of a 10 pin header would take up quite a bit of real-estate on the pcb.

Could please provide link to the programmer you ended up ordering? Many thanks

[dazz1]

Could please provide link to the programmer you ended up ordering? Many thanks

There are many shops selling the same item.  This is one of them.
https://www.aliexpress.com/item/1005004954482917.html?spm=a2g0o.order_list.order_list_main.89.23251802Ao05Ef

[dazz1]

Hi
I have now added the option of thru hole, right angle LEDs as shown on the attached screen shot.  I have designed for the Dialight 551-xx07F 3mm series.  The LEDs are orientated to point out the rear of the adapter to allow for a single piece enclosure.   The enclosure will be able to slide over the pcb and connector.

The option of the smd bi-colour LED beside the connector is still there.  The disadvantage of the SMD option is that the LEDs will only be visible one way up.

[dazz1]

Hi
The current version of the software is only designed for one red LED.  The software will not use the second green LED.   I think that two LEDs should be able to provide useful status information, especially for GPIB initial diagnostics.
I am hoping someone reading this will be interested enough to take up the challenge of modifying the code to improve visual status information from the two LEDs.  I would rather not do it myself because I haven't programmed this MCU before and I don't have the development tool chain setup.   I haven't written C code before.  I can understand it, but I haven't written it.

I propose the pair of LEDs display static on state to indicate power/connection and,
flashing to indicate activity as described below. 

Red on = Power On
Green on = GPIB device connected

Red flashing = writing data from the GPIB.  Achieved by turning off the LED for a moment.
Green flashing = reading data from the GPIB.  Achieved by turning off the LED for a moment.

There is a variable called   

Code: [Select]

s_device_stateWhen this has a value =

Code: [Select]

GPIB_DEVICE_CONNECTSTATE_CONNECTED   the adapter recognizes that the GPIB is connected to an active device and the green LED should be turned on.   The GPIB status is returned by a call to the function declared as 

Code: [Select]

bool gpib_is_connected  

The Red LED simply needs to be turned on to indicate that USB is available. 

Read/Write events can be signaled by setting booleans value each time a read or write function is called.  An ISR running at say 100Hz can turn off the related LED, then turn it back on again.  This would create an activity indicator.  Using a timer triggered ISR will minimise the computing load of the LEDs and display flashing at a rate slow enough to be recognized as flashing.


I don't think any of this would be too difficult.  It would just need some time and skill.

[dazz1]

Hi
In this world of virtual reality, I can safely say I have completed the bestest and most marvelous version of the GPIB adapter. 
Just marvel at the attached view 

Back in the real world, I have ordered the PCBs.  They will take a couple of months to get to me. 
In the mean time, I can design an an enclosure around the 3D model.  I have a 3D printer so I can try out different ideas.
I am thinking of going to a curvaceous  organically shaped enclosure because I can.  It will be a differentiating feature to the over-priced branded adapters. 

[dazz1]

Hi
OK I want to make a small modification to the C code for the adapter.   
At present, the single indicates different states:
LED blinking: The USBGPIB converter is connected to a measurement instrument, it is powered off or its GPIB port is disabled. In this state, the device is also not connected to USB and will not show up in the device manager or lsusb.
LED on: The device is connected to a measurement device and GPIB communication possible. It is also accessible over USB
LED off: The device is not connected over USB, or the PC powered off

Right now, I am still waiting for the pcb's to be delivered.  I have the necessary components to build the USB-GPIB adapter.
 
I want to program the 2nd LED to indicate read/write activity like an Ethernet connector.  The aim is to provide visual confirmation that the adapter is actively communicating with the device.
I think I can do this by triggering the LED off the GPIB-DAV signal.    Making this change would leave the code 100% compatible with the Xyphro original hardware design. 

I need to create a programming tool chain to do this.   I have been reading up on AVR compilers and there seems to be a wide choice. I don't need an IDE for the simple code changes I have in mind. The creator Xyphro appears to have used GCC.
Can anyone point to a guide on configuring GCC to compile the Xyphro code, and then programming the AVR.  I can do this with Win10 or Linux. 

 

[coromonadalix]

for the 3d case 

you could try some snapping effect between the 2 parts

for the programmer  avrdude is a preferred, avrdudess for windows ...


I would put myself in line to order 1 or 2 completed pcb's

[dazz1]

Hi
I have considered an snap enclosure, but the Centronics connectors requires too much force for such an enclosure to survive being pulled and pushed too often.

The strongest candidate I have found for a gcc based AVR tool chain is the Ubuntu version https://askubuntu.com/questions/581690/install-avr-libc

I have considered selling completed units but I had to close my child labour sweat shops.
So after factoring in:
the value of my time (I have never been paid more than half of my true value)
global warming,
carbon tax credits,
and of course the effect of inflation on the cost of wurled peas

I have a calculated a retail price of $328,231.17 plus shipping and sales tax.

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 
There could be some wiggle room on the price 

To be serious for just a moment, I doubt that it would be worth me selling individual units at any price.  I didn't start work on this project with the intention of selling units.   By far the most expensive item is the cost of assembly.   To keep that within reasonable limits, I would need a reasonable number of orders to do at one time.  Given the niche nature of this adapter, that probably won't happen.

[tautech]

But Dazz, when last I visited you have one slave labor unit still at home, can you not put him to good use ?
Or is it  ?

[Gertjan]

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 

Think out of th box!
The solution is not selling adapters, but acquiring two more test equipments with GPIB 

regards, Gertjan.

[dazz1]

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 

Think out of th box!
The solution is not selling adapters, but acquiring two more test equipments with GPIB 

regards, Gertjan.

That is the plan 

[dazz1]

...
Or is it  ?

Yes it is  and 

[dazz1]

Hi
I have been reading into the code.  The code to drive the LED doesn't match the documentation that well. 

So if I am reading the code correctly (I am a C virgin) then:
if the USB is connected, the LED stays on
Code then goes into a loop.  The LED is switched off if no GPIB device is connected.
if no GPIB device is connected and off, the LED flashes at 2Hz until.
a GPIB device is connected and on, then the LED flashes at 5Hz.

It also flashes 250ms pulses when USB data is transferred.

So the LED indicates activity, but the LED is shared between GPIB and USB.


I am looking at changing the code to show USB status/power on the RED led, and GPIB status/data transfer on the GREEN LED.
So:
RED ON = USB power on
RED Flashing Slow = USB enabled
RED Flashing Fast = USB active

GREEN OFF = no GPIB device connected.
GREEN ON = GPIB device connected and off
GREEN Flashing Slow = GPIB device connected, on and enabled.
GREEN Flashing Fast = GPIB device active.

Thoughts?  Does this make sense??

[rssenior]

Do you have a bill of materials for your version dazz1? I thought I saw one once, but I'm not seeing it now.

[dazz1]

Do you have a bill of materials for your version dazz1? I thought I saw one once, but I'm not seeing it now.

I added a BOM for the Xyphro version in issues on his Git page.

Attached is a BOM for my version with part numbers from element14. 
I now have the parts and the PCBs, but not enough time to assemble yet.

[intabits]

I now have the parts and the PCBs, but not enough time to assemble yet.

Have you assembled and tried one yet?

I'm currently designing an adapter PCB for this same connector, and as far as I can tell, your connector is arse-about.
You would need to mount it to the bottom of the PCB shown in reply #61.

Or is it me that has it wrong?

I'm looking at these connector diagrams:-
https://www.hp9845.net/9845/tutorials/hpib/  (bottom of page)
http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIoVSAU
https://www.tmatlantic.com/encyclopedia/index.php?ELEMENT_ID=14204

All these have DIO1 at top-left when looking into the connector with the wide side at the left. And that would also go to the top-left pad on your PCB, but your DIO1 is at the bottom-left!?

I was just about to send my design to JCLPCB after a final check, but now I'm confused....

[dazz1]

I now have the parts and the PCBs, but not enough time to assemble yet.

Have you assembled and tried one yet?

I'm currently designing an adapter PCB for this same connector, and as far as I can tell, your connector is arse-about.
You would need to mount it to the bottom of the PCB shown in reply #61.

Or is it me that has it wrong?


All these have DIO1 at top-left when looking into the connector with the wide side at the left. And that would also go to the top-left pad on your PCB, but your DIO1 is at the bottom-left!?

I was just about to send my design to JCLPCB after a final check, but now I'm confused....

No haven't assembled mine yet.  Nor did I check the connector pin-out before I sent my Gerbers out.
I started by copying other PCB designs.  If I am wrong, so are they.   I have checked the pin numbers on the connectors I have.   My PCB is OK.  Pin 1 marked on the connector puts it on the bottom left.


The boards I have are for lead-less devices.  A little challenging to solder, but I have a hot air station.

I have redesigned my PCB to use a leaded flat pack type package for the MCU.    The PCB is just a few mm deeper, but still very small.  I have not had this PCB version made.

[intabits]

My PCB is OK.  Pin 1 marked on the connector puts it on the bottom left.

Yes, same on my connector. I was following signal names rather than pin numbers.
Two of the links in my previous post appeared to be views of cable plugs looking into the mating side, but these are piggy-back, and the views were looking into the female side of them, it seems. (Or looking through the adapter to the instrument connector)

Someone else had similar confusion, but provided a definitive diagram:-
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3379350/#msg3379350

Thanks for helping clear this up.
(Now back to my orginal PCB version for JLCPCB)

[rhb]

Out of curiosity, what about the AR488 by WaveyDipole?  Why would you not use that and the Uno R3 shield @artag designed so you can plug a 24 pin IDC cable on into the shield and attach up to 10 GPIB devices using IDC Centronics coonnectors.

There is a very long thread about it on this forum.

In any case, the price of name brand GPIB adapters that aren't fakes is ridiculous.  So another design is always useful.  Thank you.

Have Fun!
Reg

[TheDefpom]

If this works OK I might be interested in one Darren, but I can only scrape together $88,666.42, I hope that is enough.

[dazz1]

If this works OK I might be interested in one Darren, but I can only scrape together $88,666.42, I hope that is enough.

I wouldn't normally accept that amount for payment.
I usually require at least a 10% deposit.   

[deepfryed]

I'm using xyphro’s UsbGpib adapter on Linux (Debian) and it works perfectly fine as a usbtmc interface. I haven't used it with any NI / proprietary tools and wrote some python using python-usbtmc  https://github.com/python-ivi/python-usbtmc

The python-usbtmc project has a udev rules sample file, I updated it to use the vendor id for the usbtmc device and update the group to dialout. So no need to run things as root. If I need to add some real time graphing, I can use python's matplotlib.

e.g.


#!/usr/bin/python3

import usbtmc
import time

# DMM 34401A
instr = usbtmc.Instrument(0x03eb, 0x1041)
print(instr.ask("*IDN?"))
print(instr.ask("SYST:ERR?"))
print(instr.ask("MEAS:VOLT:DC?"))

[dazz1]

I'm using xyphro’s UsbGpib adapter on Linux (Debian) and it works perfectly fine as a usbtmc interface. I haven't used it with any NI / proprietary tools and wrote some python using python-usbtmc  https://github.com/python-ivi/python-usbtmc

I haven't even begun to look at code but I will definitely bookmark that link.  I will need to start by learning Python.

[dragon5]

Check the gpib4pi board released in 2023. It provides GPIB interface solution based on linux-gpib toolchain and its bitbang driver. It is 100% open-source  hardware (OSHWA certified NO000003 - https://certification.oshwa.org/no000003.html ). It has a standard IEEE-488 compliant SN75160/1 drivers. You can set up a wireless LAN/GPIB gateway with a Raspberry Pi Zero W described in this application note https://www.hackster.io/lightside-instruments/wireless-lan-gpib-gateway-with-open-source-hardware-6e0af8

[dazz1]

Check the gpib4pi board released in 2023. It provides GPIB interface solution based on linux-gpib toolchain and its bitbang driver. It is 100% open-source  hardware (OSHWA certified NO000003 - https://certification.oshwa.org/no000003.html ). It has a standard IEEE-488 compliant SN75160/1 drivers. You can set up a wireless LAN/GPIB gateway with a Raspberry Pi Zero W described in this application note https://www.hackster.io/lightside-instruments/wireless-lan-gpib-gateway-with-open-source-hardware-6e0af8

Hi
I am committed to the USB-GPIB adapter.  I have modified the pcb design (twice) and figured out what software mods I need to make for my two LED version.  The pcbs and parts are waiting for me to put them together. 

[artag]

Out of curiosity, what about the AR488 by WaveyDipole?  Why would you not use that and the Uno R3 shield @artag designed so you can plug a 24 pin IDC cable on into the shield and attach up to 10 GPIB devices using IDC Centronics coonnectors.

There is a very long thread about it on this forum.

In any case, the price of name brand GPIB adapters that aren't fakes is ridiculous.  So another design is always useful.  Thank you.

Have Fun!
Reg

The initial question in this thread was to find an adapter which can be accessed through the Visa API. The AR488 doesn't do that - it emulates the  Prologix USB adapter, which communicates over a serial-over-USB emulation.

I guess it's possible to write a Visa interface for Prologix but I don't know that anyone's done that. Or modify the python interface to use Prologix instead of Visa, but then you end up with a Python API which is another ratsnest of incompatibility.

It's also possible, with some reassignment of pins, to make the xyphro software work with AR488 hardware. However, the xyphro software makes better use of the Atmega's pins : some are not available on the Arduino boards which results in inefficiences such as having to bit-address some ports instead of byte-address. IIRC I laid out the Arduino Pro Micro pcb to work as well as possible (eg write the 8 bit data port in only two writes) but the original xyphro assignment is better.

[maxwell3e10]

Could you post your version of the code for Arduino Pro Micro? I'd like to try it, without having to make a custom PCB.

[caiser01]

The initial question in this thread was to find an adapter which can be accessed through the Visa API. The AR488 doesn't do that - it emulates the  Prologix USB adapter, which communicates over a serial-over-USB emulation.

I guess it's possible to write a Visa interface for Prologix but I don't know that anyone's done that. Or modify the python interface to use Prologix instead of Visa, but then you end up with a Python API which is another ratsnest of incompatibility.

I use my AR488 adapters with pyvisa exclusively and they work great. Here's an example for reading DC voltage from an HP 34401A:

Code: [Select]

import pyvisa
from sys import platform

rm = pyvisa.ResourceManager('@py')

if platform == "linux" or platform == "linux2":
    # Linux
multimeter = rm.open_resource('ASRL/dev/ttyUSB0::INSTR')
elif platform == "darwin":
    # macOS
multimeter = rm.open_resource('ASRL/dev/cu.usbmodem101::INSTR')
elif platform == "win32":
    # Windows, COMx = ASRLx
multimeter = rm.open_resource('ASRL19::INSTR')

multimeter.write('++rst')
multimeter.close()
sleep(2)
multimeter.open()

multimeter.baud_rate = 115200
multimeter.timeout = 5000
multimeter.write_termination = '\n'
multimeter.read_termination = '\n'

multimeter.write('++addr 22')
multimeter.write('++auto 2')
multimeter.write('++eos 2')
multimeter.write('++eoi 1')

multimeter.write('*RST')
multimeter.write('*CLS')
print(multimeter.query('*IDN?'))
multimeter.write('CONF:VOLT:DC 10,0.001')
try:
while(True):
    print(multimeter.query('READ?'))
except KeyboardInterrupt:
    multimeter.write('*RST')
    multimeter.write('*CLS')
    multimeter.write('++loc')
    multimeter.close()
    rm.close()


It's also possible, with some reassignment of pins, to make the xyphro software work with AR488 hardware. However, the xyphro software makes better use of the Atmega's pins : some are not available on the Arduino boards which results in inefficiences such as having to bit-address some ports instead of byte-address. IIRC I laid out the Arduino Pro Micro pcb to work as well as possible (eg write the 8 bit data port in only two writes) but the original xyphro assignment is better.

I'm wondering if the opposite is true, i.e. that you can use AR488 software with the xyphro hardware by changing up the pin assignments. I've been playing around with xyphro adapters and I like the form factor. I'd be interested in trying to get the AR488 firmware running on the xyphro adapter...

[coromonadalix]

you have to remap some pins  ...

[caiser01]

Looking at the schematics for the xyphro vs the Arduino Pro Micro, I think it is possible to run AR488 on the xyphro adapter but I think it requires a custom Arduino board definition. Two of the pins the xyphro uses as data lines are used as the RX and TX LEDs on the Pro Micro, so I think you'd need an Arduino board definition that remapped those to other pins to be able to flash AR488 on the xyphro hardware.

I might give it a shot if I have enough time to kill one day...

[dazz1]

I have assembled one USB-GPIB adapter and I am now trying to load the firmware. 

I have an Aliexpress usbasp programmer.  I am running avrdude on Ubuntu.
I have successfully run the following commands:

Code: [Select]

avrdude -P usb -c usbasp -p m32u4 -e -Uefuse:w:0xcb:m
avrdude -P usb -c usbasp -p m32u4 -e -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m
avrdude -P usb -c usbasp -p m32u4  -U flash:w:BootLoader.hexavrdude -P usb -c usbasp -p m32u4 -e -U flash: "FLASH.BIN" -vvvv

These commands are based on instructions earlier in this thread and they return messages of success.
For the benefit of others:
-P the port
-c programmer type
-p MCU type
-e erase first.  Necessary before programming.

see

Code: [Select]

/etc/avrdude.conf   and

Code: [Select]

man avrdude or/and
https://www.nongnu.org/avrdude/user-manual/avrdude_3.html#Option-Descriptions
for full details.

I am now stuck on what to do next.  I understand this is a copy command, but I can't figure out what my destination should be.  I was expecting another avrdude command at this point.

Code: [Select]

cp TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN #  verify with md5sum, umount, unplug

[deepfryed]

I am now stuck on what to do next.  I understand this is a copy command, but I can't figure out what my destination should be.  I was expecting another avrdude command at this point.

Code: [Select]

cp TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN #  verify with md5sum, umount, unplug

Did you see the note re. Linux on the README ?

On Linux, there is a bug with the LUFA mass storage that means it is required to use

Code: [Select]

dd if=TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync


[dazz1]

Did you see the note re. Linux on the README ?

Yes, I did not see the note.

Code: [Select]

dd if=TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync


The dd command is one I only use as the option of last resort. 

I think the root of my problem is a dumb assumption.  I assumed that the initial firmware would be all loaded via the programmer.   
I now see that the process requires the programming of the the boot loader via the ISP connector, followed by copying the firmware via the usb connector.

OK so I have connected Win10 (dual-boot PC) to the usb-gpib usb-C connector.  I see:

Code: [Select]

GPIBUSBBOOT(D:)
   EEPROM.BIN                   1KB
   FLASH.BIN                     24KB

So that looks like it is working.
Then I tried copying TestandMeasurement.bin via the usb connector and got the error message in the attached image.
FLASH.BIN is taking up all the space. 


For me, it makes no sense to re-program via the USB port. 
To enable the boot loader to load new firmware, I need to remove the enclosure and short two pins on the ISP connector.   Then download the firmware via the usb connector using the data destroyer dd command or Win10 copy.

If I re-program the firmware via the ISP connector, I need to remove the enclosure and plug in my usbasp programmer using the benign avrdude program. 

To use the usb connector really requires an externally accessible push switch to short the ISP pins without removing the enclosure.  I did look at this option when designing my PCB but did not include one.    I think I will add that option on the pcb (fit for but not with).

I have make progress.  I have confirmed:
the ISP works,
the usb-C works,
the MCU works.

but I have not yet been able to load the usb-gpib firmware.  I am still doing something wronng.

[deepfryed]

In theory, you could use the arduino style bootloader and just program directly from USB without shorting any pins. I'm not sure why the flash bootloader was chosen 

[dazz1]

In theory, you could use the arduino style bootloader and just program directly from USB without shorting any pins. I'm not sure why the flash bootloader was chosen 

Right now I am just trying to get the firmware installed and running.  I plan to modify the software to run the two status LEDs because two LEDs is always better than one.

[dazz1]

I am thinking if I don't install (delete) FLASH.BIN, I will have enough space for the usb-gpib firmware.  My understanding of the software is that the FLASH.BIN code is only called if the 2 pins on the ISP connector are shorted. 

[deepfryed]

Code: [Select]

avr-size --mcu=atmega32u4 --format=avr TestAndMeasurement.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program:    9190 bytes (28.0% Full)
(.text + .data + .bootloader)

Data:        241 bytes (9.4% Full)
(.data + .bss + .noinit)

I shouldn't take a lot of space. I followed the instructions on getting the bootloader flashed, unplug and plug usb back in, short pin 4 & 6 of the ISP header (MOSI & GND) for abour 3 seconds and the bootloader should appear as a flash drive. Mount it and then copy the file across

Code: [Select]

sudo mount /dev/sdb /media/avr
sudo dd if=TestAndMeasurement.bin of=/media/avr/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync
sudo umount /media/avr

This works as advertised for me.

[dazz1]

For me the problem is that the FLASH.BIN file is taking up 24kB of 32kB memory, so no room for the measurement app file.

[deepfryed]

what is the FLASH.BIN file ?

There are 2 artefacts, the bootloader.hex and the TestAndMeasurement.bin files. The bootloader is programmed through the avrdude command as described in the readme.

Once the bootloader presents the device as a flash drive, you copy the  TestAndMeasurement.bin file to the drive and name it FLASH.BIN, that way the bootloader can program the flash once the file is written.

avr-size tells me TestAndMeasurement.elf is about 9K, should not be anywhere close to 20k+

[dazz1]

FLASH.BIN  appears way back in reply No.41.   I missed the bit about renaming it.
I will do what you have done and that should work.

[dazz1]

Hi
I didn't do what you said.  I tried something else. 
I started by copying the TestAndMeasurement.bin file to FLASH.BIN.  Same file, different name.
For all of the commands below, the USB-GPIB adapter was connected to a usbasp programmer via the ISP connector. 

I ran this command in Linux:

Code: [Select]

>$ avrdude -P usb -c usbasp -p m32u4 -e -U flash:w:FLASH.BIN

and got the following messages in response:

Code: [Select]

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "FLASH.BIN"
avrdude: input file FLASH.BIN auto detected as raw binary
avrdude: writing flash (9312 bytes):

Writing | ################################################## | 100% 5.40s

avrdude: 9312 bytes of flash written
avrdude: verifying flash memory against FLASH.BIN:
avrdude: load data flash data from input file FLASH.BIN:
avrdude: input file FLASH.BIN auto detected as raw binary
avrdude: input file FLASH.BIN contains 9312 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.74s

avrdude: verifying ...
avrdude: 9312 bytes of flash verified

avrdude: safemode: Fuses OK (E:F3, H:D8, L:FF)

avrdude done.  Thank you.
After this, the status LED started flashing on the GPIB adapter.  So this looks like success.

I like writing this sort of thing into Linux shell scripts to reduce the chance of error.  I have 4x more adapters to build and program.  A script means I can exactly reproduce a complex command sequence.
My script looks like this:

Code: [Select]

#!/bin/bash
# uploads usb-gpib firmware to usb-gpib adapter.

# version 1.2 13 Nov 2023


avrdude -P usb -c usbasp -p m32u4 -e -Uefuse:w:0xcb:m
avrdude -P usb -c usbasp -p m32u4 -e -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m
avrdude -P usb -c usbasp -p m32u4  -U flash:w:BootLoader.hex
# -> yields
#  avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)
# copy the TestAndMeasurement.bin file to FLASH.BIN.  Probably not necessary, but it worked.
# This command loads the firmware.
avrdude -P usb -c usbasp -p m32u4 -e -U flash:w:"FLASH.BIN"
# run this command to read and verify the firmware
avrdude -P usb -c usbasp -p m32u4 -U flash:v:"FLASH.BIN"
At the end of running these commands, the status LED slowly flashed on the usb-GPIB adapter.    So it all appears to have worked.
I then tried shorting the two ISP pins to try and get the adapter to appear as a drive, but that didn't work.

The final test I haven't done is to try controlling a device.  I have a HP 3478A multi-meter.    I just need to find some software compatible with the adapter.  One I tried was looking for a COM port.

[dazz1]

Hi
I may have found the bug mentioned in the README file.
When I plug in the adapter into the PC USB, it tells me the USB device is not recognised.
Yesterday I successfully uploaded the firmware from the PC to the adapter with the same cable and that worked OK.   So I don't think I have a hardware problem. The leading hypothesis is that using avrdude to load the firmware has exposed the bug.

[dazz1]

I found some ready-made GPIB control software here:
https://www.eevblog.com/forum/testgear/hp-34401a-standalone-software/
I just need to get my adapter working first.

With the usb interface malfunctioning, I can't over-write the existing software via the usb connection.  I will have to do it with avrdude. 

[caiser01]

I didn't do what you said.  I tried something else.

deepfryed was telling you the right way to do it, which is the way xyphro outlines in his README on GitHub (https://github.com/xyphro/UsbGpib)

When I plug in the adapter into the PC USB, it tells me the USB device is not recognised.
Yesterday I successfully uploaded the firmware from the PC to the adapter with the same cable and that worked OK.   So I don't think I have a hardware problem. The leading hypothesis is that using avrdude to load the firmware has exposed the bug.

Since you deviated from the flashing process that the developer recommends, I would first try erasing and re-flashing using xyphro's instructions exactly before assuming there is a bug. I have flashed several of these adapters without issue by following the xyphro's instructions, and they work correctly afterward. If you prefer to script the process, as you showed in your earlier post, that's fine but the process should still follow what is outlined by the developer.

Once the adapter has been flashed and you see the LED blinking, you can connect the adapter to an instrument. One simple method of testing is by using the pyvisa-shell application (https://pyvisa.readthedocs.io/en/latest/introduction/shell.html). This will allow you to interactively communicate with the instrument to test basic functionality. Alternatively if you have a VISA implementation from one of the commercial vendors, they all include a utility that allows you to interactively send commands to and read from the instrument. My personal favorite is Rohde & Schwarz (https://www.rohde-schwarz.com/us/applications/r-s-visa-application-note_56280-148812.html). The R&S Tester app will allow you to quickly check communication with an instrument.

Finally, if you're familiar with Python, here is a simple script that can be used to read from the HP 3478A you mentioned in your earlier post. Please note: Your VISA resource string will be different because your adapter will have a different serial number to mine.

Code: [Select]

# HP 3478A Multimeter simple read test

import pyvisa

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

# Set function to DC volts
multimeter.write('F1')

try:
    while True:
        print(float(multimeter.read().strip()))
except KeyboardInterrupt:
    multimeter.clear()
    multimeter.close()
    rm.close()


[dazz1]

I didn't do what you said.  I tried something else.

deepfryed was telling you the right way to do it, which is the way xyphro outlines in his README on GitHub (https://github.com/xyphro/UsbGpib)

When I plug in the adapter into the PC USB, it tells me the USB device is not recognised.
Yesterday I successfully uploaded the firmware from the PC to the adapter with the same cable and that worked OK.   So I don't think I have a hardware problem. The leading hypothesis is that using avrdude to load the firmware has exposed the bug.

Since you deviated from the flashing process that the developer recommends, I would first try erasing and re-flashing using xyphro's instructions exactly before assuming there is a bug. I have flashed several of these adapters without issue by following the xyphro's instructions, and they work correctly afterward. If you prefer to script the process, as you showed in your earlier post, that's fine but the process should still follow what is outlined by the developer.

Once the adapter has been flashed and you see the LED blinking, you can connect the adapter to an instrument. One simple method of testing is by using the pyvisa-shell application (https://pyvisa.readthedocs.io/en/latest/introduction/shell.html). This will allow you to interactively communicate with the instrument to test basic functionality. Alternatively if you have a VISA implementation from one of the commercial vendors, they all include a utility that allows you to interactively send commands to and read from the instrument. My personal favorite is Rohde & Schwarz (https://www.rohde-schwarz.com/us/applications/r-s-visa-application-note_56280-148812.html). The R&S Tester app will allow you to quickly check communication with an instrument.

Finally, if you're familiar with Python, here is a simple script that can be used to read from the HP 3478A you mentioned in your earlier post. Please note: Your VISA resource string will be different because your adapter will have a different serial number to mine.

Code: [Select]

# HP 3478A Multimeter simple read test

import pyvisa

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

# Set function to DC volts
multimeter.write('F1')

try:
    while True:
        print(float(multimeter.read().strip()))
except KeyboardInterrupt:
    multimeter.clear()
    multimeter.close()
    rm.close()


I agree with all of the above but I generally don't learn a lot by just following the instructions.  I want to modify the Xyphro software to run on my hardware, while remaining compatible with the Xyphro version.    To do that I need a deeper understanding of programming model and tool chain.  I have programmed in a number of languages but not Python or C++ so I intend to learn.    Before this project, I had never heard of avrdude but now I can write usable commands.

I will use those links to the gpib type software.  They will be useful as a confidence check and for diagnostics.

My understanding is that it should be possible to program the firmware by flashing one image to avoid the need for the two step process that can't be scripted (unplug/plug in the adapter).  It appears the way to do that with the Xyphro software is to use avrdude to read back an image of a fully flashed usb-gpib adapter flash and use that to write to other un-programmed adapters.  When first plugged in, the adapter would not appear as a memory device.

I have avrdude installed on the windows side so I am going to play around with that.  If things get truly desperate,  I might even be forced to follow the instructions. 

[caiser01]

My understanding is that it should be possible to program the firmware by flashing one image to avoid the need for the two step process that can't be scripted (unplug/plug in the adapter).  It appears the way to do that with the Xyphro software is to use avrdude to read back an image of a fully flashed usb-gpib adapter flash and use that to write to other un-programmed adapters.

If you want a single hex file that combines the bootloader and GPIB application, there's another way that might be easier. Go get SRecord (https://srecord.sourceforge.net/) and use srec_cat to concatenate the hex files for the bootloader and the application. Both hex files are available already compiled in xyphro's repository. The command to concatenate them will look similar to this:

Code: [Select]

srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o combined.hex -Intel
That should give you a single hex file you can flash with avrdude in one step.

I would still encourage you to flash one adapter by the original instructions so you have a known good baseline before you start changing things.

[dazz1]

I previously completed firmware programming in Linux and Windows.  The 2nd part of loading the firmware while the adapter pretended to be a memory device, so I have high confidence that the hardware, including usb, is working.
Current plan is to use avrdude on the Windows side to reprogram the firmware.

Programming with HEX files looks promising.

The problem I am having is that I need to link up the GPIB equipment, the adapter, and some GPIB software that matches the equipment.  If any one of those links don't work, the whole chain is broken.

It would be useful to have a simple program for confidence checking of the adapter.  To a limited extent, the flashing LED indicates programming success.  I am thinking of a program that flashes the LED (oscilloscope trigger), then pulsing individual MCU pins in timed sequence.  Such a simple program would allow a good test  of the adapter hardware with any oscilloscope.  It would actually be a good test of the whole adapter without dependencies.

[caiser01]

It would be useful to have a simple program for confidence checking of the adapter.  To a limited extent, the flashing LED indicates programming success.  I am thinking of a program that flashes the LED (oscilloscope trigger), then pulsing individual MCU pins in timed sequence.  Such a simple program would allow a good test  of the adapter hardware with any oscilloscope.  It would actually be a good test of the whole adapter without dependencies.

I think I understand what you're getting at; a sort of "factory test" of the GPIB adapter. If the virtual USB drive part worked for flashing then you've already confirmed USB is working. There's 16 I/O pins you need to check for the GPIB signals. I can see how you could use the LED as a trigger and then pulse each GPIB pin in turn. Another option is to make a really simple test jig that would plug on to the GPIB connector of the adapter. I might just have 16 LEDs tied together common-cathode with a single current limiting resistor. Program the micro to do a simple, single light chaser pattern across the LEDs and that should tell you those pins are okay.

Since you've designed your own board, the most important thing is probably to confirm that you've routed the signals from the micro to GPIB connector identically to the original xyphro design. Once you're certain of that, you can be confident that the original firmware will work correctly. Then with xyphro's firmware on the adapter, install R&S VISA on your PC (not much to go wrong there), plug up to an instrument, and try to send a command and/or read some data. If you can do that, you can be confident that everything in the chain is working. Then you can move on to fiddling with the adapter code to add your second LED functionality.

But be warned! Timing is super important for the GPIB handshake and data signals! If the code you add for your second LED interferes with any of that, it may break the core GPIB functionality.

[dazz1]

I think I understand what you're getting at; a sort of "factory test" of the GPIB adapter. 

Yes, that is exactly what I would have done if I developed this project.

  If the virtual USB drive part worked for flashing then you've already confirmed USB is working.   

 
After doing some testing today, I am less confident the USB drive part is working.   Hmmmm.

There's 16 I/O pins you need to check for the GPIB signals. I can see how you could use the LED as a trigger and then pulse each GPIB pin in turn.   

 
Yes. 

Another option is to make a really simple test jig that would plug on to the GPIB connector of the adapter. I might just have 16 LEDs tied together common-cathode with a single current limiting resistor. Program the micro to do a simple, single light chaser pattern across the LEDs and that should tell you those pins are okay.   

 
Yes that would work, but I figure that anyone who wants a usb-gpib adapter is going to have an oscilloscope, and would not build an LED panel. 

In my case, I have a HP 54645D scope complete with logic analyzer probes.  So if I make up a board with male/female GPIB connectors, and a connector for the HP 54645D LA cable, I can plug in the probe cable and record GPIB signals.  That is a feature I could have used to help recent fault finding efforts by others. 

Since you've designed your own board, the most important thing is probably to confirm that you've routed the signals from the micro to GPIB connector identically to the original xyphro design. Once you're certain of that, you can be confident that the original firmware will work correctly.   

 
I checked my board design against Xyphro netlist (slightly modified) so I have high confidence my board is electrically correct.  I cannot be certain that the solder joints and actual pcb is fault free.

Then with xyphro's firmware on the adapter, install R&S VISA on your PC (not much to go wrong there), plug up to an instrument, and try to send a command and/or read some data. If you can do that, you can be confident that everything in the chain is working. Then you can move on to fiddling with the adapter code to add your second LED functionality. 

 
Yes.  I am running Xyphro's firmware as-is, without modification.

But be warned! Timing is super important for the GPIB handshake and data signals! If the code you add for your second LED interferes with any of that, it may break the core GPIB functionality.

I have already figured out what modifications I want to do.  Driving 2 LEDs will be no more time consuming than one.   Possibly slightly less.

From the windows side, using a USB-ASP programmer, I cleared FLASH and burned the bootloader.  When I plug the adapter into the PC USB, it does not show as a USB device.  Same is true when I short the ISP pins.  I haven't yet tried the cat HEX app.

[caiser01]

From the windows side, using a USB-ASP programmer, I cleared FLASH and burned the bootloader.

What commands did you use to do this?

[dazz1]

What commands did you use to do this?

I followed the Xyphro instructions with these commands:

Code: [Select]

avrdude -P usb -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m
avrdude --p usb c usbasp -p m32u4 -U flash:w:BootLoader.hex
Then I connected the adapter to the PC usb port and,   ....    nothing.
Yesterday I was getting beeps and error messages about usb but I think what I actually did was over-write the BootLoader file with the  TestandMeasurement file.

I have not yet got to trying the concat hex file thing.

Some time later .....

I wrote the TestAndMeasurement.bin file to the adapter using the usbasp programmer.  Yes, I now realize this wipes out the bootloader. [Edit:  I now know the bootloader is not overwritten because it resides in a different part of memory]    What it does do is run the TestAndMeasurement firmware.  This causes the LED to flash at about 0.3Hz but the PC no longer detects the usb connection being made.  That is new.  Most likely a hardware fault because I have not changed the software.

[caiser01]

I wrote the TestAndMeasurement.bin file to the adapter using the usbasp programmer.  Yes, I now realize this wipes out the bootloader.    What it does do is run the TestAndMeasurement firmware.  This causes the LED to flash at about 0.3Hz but the PC no longer detects the usb connection being made.  That is new.  Most likely a hardware fault because I have not changed the software.

That is the correct behavior for the GPIB application firmware. The light will blink and no USB device will show up until you connect it to the GPIB port of an instrument and power the instrument on. The adapter will then detect the instrument and present itself to the PC as a USB device with the appropriate VISA resource string. xyphro describes his philosophy behind this behavior here: https://github.com/xyphro/UsbGpib#usb-enumeration

[dazz1]

That is the correct behavior for the GPIB application firmware. The light will blink and no USB device will show up until you connect it to the GPIB port of an instrument and power the instrument on. The adapter will then detect the instrument and present itself to the PC as a USB device with the appropriate VISA resource string. xyphro describes his philosophy behind this behavior here: https://github.com/xyphro/UsbGpib#usb-enumeration

Yes, but I am no longer seeing a usb  connection on my PC regardless of what I do.  At present the adapter is plugged into a gpib device (HP 3478A), the LED is flashing, but the PC does not see the usb adapter.  I am working to the hypothesis that there is a hardware fault on the usb section.   The first step is to concat the bootloader and TestAndMeasurement files to see if I can get the adapter to present itself as a CD-ROM.

[alan.bain]

I have a little direct adaptor Ethernet to GPIB built around a STM32 F439ZI Nucleo and a small daughter board with bus transceivers (so it can operate multiple devices). It seems to work well and at some point I produced a PCB with the whole lot on it to avoid needing the Nucleo, must test someday (the prototype worked well enough it just got used).

It speaks a Prologix like command set and seems featured enough to run an HP3048 type phase noise setup.  It doesn't support parallel poll because I didn't need it and never wrote the software although the hardware should support it.

It's very convenient as the whole equipment rack is connected to ethernet and can happily be controlled by any wifi device without lots of USB wires to risk pulling off surface mount USB micro sockets!

(Happy to share the firmware source code / put in public domain for others to use)

[dazz1]

I have taken a closer look at the HEX files.  I think they already include the correct memory address locations.  It should be possible to load both with them ending up in the right locations in flash.
So from the windows side, I ran the avrdude command shown in the attached screen snip.

The response indicated successful programming.  When I plugged the adapter into the PC usb port, nothing.  No flashing LED, no ding from the PC to indicate a USB connection.  The later may be the usb hardware fault. 

When I run the the avrdude command that only programs the TestAndMeasurement.hex and not the BootLoasder.hex

Code: [Select]

avrdude -c usbasp -p m32u4 -U flash:w:TestAndMeasurement.hexThen I get the flashing LED back again.

It would be useful to know if both hex files can be programmed and then run on hardware known to be working.  If both hex files can be programmed with one command, that would simplify things.
The software includes a magic value which I think triggers the call to the BootLoader at address 0700h by enabling the watch dog timer, but I haven't studied this in detail.

Code: [Select]

void Jump_To_Bootloader(void)
{
    // If USB is used, detach from the bus and reset it
    USB_Disable();
   
    // Disable all interrupts
    cli();
   
    // Wait two seconds for the USB detachment to register on the host
    Delay_MS(2000);
   
    // Set the bootloader key to the magic value and force a reset
    //Boot_Key = MAGIC_BOOT_KEY;
    wdt_enable(WDTO_250MS);
    Delay_MS(500);
((void (*)(void))0x7000)();
    for (;;);
}
The next thing I will do is some troubleshooting of the USB hardware to see if I can find something.

[caiser01]

Okay, I combined the two original hex files from xyphro's repository with this command:

Code: [Select]

srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o UsbGpib-combined.hex -Intel
Then I programmed that combined hex file to one of my five working adapter of xyphro's hardware design using this command:

Code: [Select]

avrdude -c atmelice_isp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:UsbGpib-combined.hex
Right away the LED started flashing. I shorted the two pins on the programming header and the virtual USB drive appeared on my PC as expected. Unplugged and replugged the USB cable and then connected the adapter to my HP 5385A frequency counter. The USBTMC device became visible and then I was able to talk to the counter interactively from Python.

So the hex file attached below when flashed to the hardware I have results in a working UsbGpib adapter.

[dazz1]

Okay, I combined the two original hex files from xyphro's repository with this command:

Code: [Select]

srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o UsbGpib-combined.hex -Intel
Then I programmed that combined hex file to one of my five working adapter of xyphro's hardware design using this command:

Code: [Select]

avrdude -c atmelice_isp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:UsbGpib-combined.hex
So the hex file attached below when flashed to the hardware I have results in a working UsbGpib adapter.

OK so that is good progress.  It will make initial programming of the adapter a lot easier.  A very simple script/batch file will do it.  It could also be done with adding to the MAKE file.

I am still confident that both hex files can be programmed with the one avrdude call.   The hex files already include the right addresses to correctly place them in memory space.   I didn't set the fuses when I tried because they were already programmed.  Using just avrdude would avoid the need to install srec.  Just one less thing to go wrong.

I am still working to the hypothesis that I have a usb hardware fault, so any failure with my avrdude command is probably due to that fault.  I need to do fault finding.  I have only assembled one of five pcbs to ensure I haven't introduced any design errors.

[alan.bain]

Thie attachment shows the ethernet to GPIB adaptor that I use (sitting ontop of the inevitable HP box). As you can probably see this one was hand soldered (!)  The central LQFP-144 is the STM32F439ZET6 and the SOICs to right the bus drivers. Voltage regulators on left and the ethernet PHY chip is on the underside.

[caiser01]

Thie attachment shows the ethernet to GPIB adaptor that I use (sitting ontop of the inevitable HP box). As you can probably see this one was hand soldered (!)  The central LQFP-144 is the STM32F439ZET6 and the SOICs to right the bus drivers. Voltage regulators on left and the ethernet PHY chip is on the underside.

Nice design! I'd be interested to see the source code if/when you want to share. Might be interesting to see about porting to a lower pin count version of the STM32F4 for easier assembly. Still this is very cool!

[alan.bain]

Yes. An awful lot of those GPIO pins are unused   I think I ended up in the larger chips because of the ethernet requirement - but stock levels also played a factor (as in I needed something suitable that digikey or mouser actually had in stock when I was building the prototype).  The 500Mb flash version was fine - RAM is the main limiting factor.  I'll work out a way to share the source code / gerbers / kicad files - very happy to do that if it can help someone else.  It was a fun project but has also proved useful.

[caiser01]

Yes. An awful lot of those GPIO pins are unused   I think I ended up in the larger chips because of the ethernet requirement - but stock levels also played a factor (as in I needed something suitable that digikey or mouser actually had in stock when I was building the prototype).  The 500Mb flash version was fine - RAM is the main limiting factor.  I'll work out a way to share the source code / gerbers / kicad files - very happy to do that if it can help someone else.  It was a fun project but has also proved useful.

You mentioned your adapter uses a command set like the Prologix and AR488. How do you interface with it from the PC? Is there an embedded web page? Or is a TCP/IP socket sort of thing?

[alan.bain]

I used tcpip sockets. I wanted to be able to write simple software to perform complex measurements e.g. phase noise and it's very easy to open a socket and talk in sockets it from C++/C/Python.  There are two sockets one 1234 is the control/data socket over which commands can be sent (e.g. enable EOI, choice of termination chars) and data to and from the device. The other one on port 1235 is a monitor socket which shows the data going back and forth to the device and which is very useful for debugging a device that isn't behaving (I don't have a 54901A!).

It can use NVRAM (mimiced by the STM32 flash) to store default config.  IP address is established either by DHCP or can be static (there's a chicken and egg situation here for setting the IP the first time as the device doesn't have any other ports - by default it will use DHCP and then let you configure a default address. I'm sure there's a better way but I haven't thought of it. The little switched does a reset to default config.

[dazz1]

Okay, I combined the two original hex files from xyphro's repository with this command:

Code: [Select]

srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o UsbGpib-combined.hex -Intel
Then I programmed that combined hex file to one of my five working adapter of xyphro's hardware design using this command:

Code: [Select]

avrdude -c atmelice_isp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:UsbGpib-combined.hex
So the hex file attached below when flashed to the hardware I have results in a working UsbGpib adapter.

OK so that is good progress.  It will make initial programming of the adapter a lot easier.  A very simple script/batch file will do it.  It could also be done with adding to the MAKE file.

I am still confident that both hex files can be programmed with the one avrdude call.   The hex files already include the right addresses to correctly place them in memory space.   I didn't set the fuses when I tried because they were already programmed.  Using just avrdude would avoid the need to install srec.  Just one less thing to go wrong.

I am still working to the hypothesis that I have a usb hardware fault, so any failure with my avrdude command is probably due to that fault.  I need to do fault finding.  I have only assembled one of five pcbs to ensure I haven't introduced any design errors.

OK I used srec-cat to program the adapter.  That worked.  I did a dump on the flash memory.
I then ran the following command to program the adapter just using avrdude:

Code: [Select]

..\avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:TestAndMeasurement.hex -U flash:w:BootLoader.hexand did another flash memory dump.  Both dumps are identical.  That means there is no requirement to install and run srec-cat.  Programming both files can be done with a single command and this should mean the adapter is ready to run straight away.

My adapter still won't run with both files installed.  It takes power from the USB-C, but the LED won't flash at all under any circumstances.  I have to erase/not program the BootLoader.hex file. 
With the adapter plugged into my HP 3478A Multi-meter, the usb does not register on my PC.
I gave the board a really good clean (acetone/IPA) to get rid of any trace of flux.
I did a continuity check of the USB data lines to make sure they were OK between the connector and the MCU.
I cannot find a hardware fault so far. 

When I program just the TestAndMeasurement.hex file without the BootLoader, the LED starts flashing again.
When I connected the adapter to a Linux laptop and ran

Code: [Select]

>lsusb The adapter did not show (as expected).
When I then connected the adapter to my HP 3478A, and ran

Code: [Select]

>lsusb again, no show.

I have an issue with the USB.  I have swapped cables with no change. 

[caiser01]

Code: [Select]

..\avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:TestAndMeasurement.hex -U flash:w:BootLoader.hex

Running your command above to program one of my known good boards still results in a fully working adapter for me.

I have an issue with the USB.

Maybe, but the fact that your LED never blinks whenever the bootloader is in flash makes me suspect at least part of your problem lies elsewhere. I'm suspicious you have a short or a bad solder connection on at least one of the AVR pins. In particular, I'm wondering if you could have a short or intermittent connection to ground from pin 10 of the AVR since the bootloader is invoked by grounding that pin.

For QFN parts, I've had good luck clearing solder issues by heating the chip until the solder reflows, then giving the chip a few gentle but firm taps right in the center with handle of my tweezers.

[dazz1]

I definitely have some sort of hardware issue that is unique to my assembly.  I went through the USB design last night to make sure I hadn't made a mistake because this is a difference with the Xyphro design. 
A bad solder joint or solder bridge is definitely a candidate.  My symptoms are consistent with pin 10 grounded. 

Tests of programming the firmware (by me and others) confirm that is not where my problem is.  A single line command that can be run in a batch/bash script will make programming easier for everyone.  Especially for those building their first adapter.

[dazz1]

I used tcpip sockets. I wanted to be able to write simple software to perform complex measurements e.g. phase noise and it's very easy to open a socket and talk in sockets it from C++/C/Python.  There are two sockets one 1234 is the control/data socket over which commands can be sent (e.g. enable EOI, choice of termination chars) and data to and from the device. The other one on port 1235 is a monitor socket which shows the data going back and forth to the device and which is very useful for debugging a device that isn't behaving (I don't have a 54901A!).

It can use NVRAM (mimiced by the STM32 flash) to store default config.  IP address is established either by DHCP or can be static (there's a chicken and egg situation here for setting the IP the first time as the device doesn't have any other ports - by default it will use DHCP and then let you configure a default address. I'm sure there's a better way but I haven't thought of it. The little switched does a reset to default config.

I discovered the MQTT protocol today.  At first glance it could be applied to GPIB networked comms.

[dazz1]

Maybe, but the fact that your LED never blinks whenever the bootloader is in flash makes me suspect at least part of your problem lies elsewhere. I'm suspicious you have a short or a bad solder connection on at least one of the AVR pins. In particular, I'm wondering if you could have a short or intermittent connection to ground from pin 10 of the AVR since the bootloader is invoked by grounding that pin.

For QFN parts, I've had good luck clearing solder issues by heating the chip until the solder reflows, then giving the chip a few gentle but firm taps right in the center with handle of my tweezers.

I found a solder bridge on the MCU pins 36/37.  I cleared that and now the LED flashes/stays on when it should.  That is a step forward.
The USB is not enumerating so possibly a bad solder joint there.  I have already re-checked my design and it seems to be OK. 

[dazz1]

I soldered two wire-wrap wires to the USB D- and D+ lines on the connector side of the 22R series resistors.  I wanted to see what data was reaching the connector.
Many techs start fault finding from one end of the signal path.  It is a lot faster to start in the middle of the signal path and just repeat the halving process until the fault is found.  If (say) there are 16 test points in a signal path, and one is faulty, halving the signal path will find the fault in no more than 4 tests.

In all cases, with the adapter plugged into an operating GPIB bus, the LED would flash once, then remain on, indicating a valid connection to a live GPIB bus.  If the GPIB bus was made inactive, (turning off the test equipment), the LED started flashing.  No evidence of any issue with the GPIB bus, MCU or software.

I did see usb renumeration, but only if the USB-C cable was plugged in one way.  If the plug was rotated 180 degrees, there was no USB traffic. 
I swapped cables.  Same symptoms.
Static testing of the USB-C connector showed no solder bridges.
Checked all the resistors in-circuit with the USB connector. 
I (re)checked the connector data sheet and compared against the circuit diagram and foot print.  All good.  No problem found.
Close inspection indicated some of the solder joints might be suspect.  I resoldered the connector joints and tried again.

I have gone from renumeration one-way back to renumeration no-way.  I see no data on the USB lines.
The only thing I have touched is the USB connector, so I suspect the connector is faulty.  Swapping that out is going to be a challenge. 

Images show initial USB signal followed by streaming data and an overview of the setup.   
The computer is an old Asus eeePC running Linux.  I just wanted to see a valid USB connection (command:  lsusb )

[tautech]

Isn't USB C polarised ?

[coromonadalix]

not supposed to  if the design is verified,   that's the advantage of usb-c,   no up / down nightmares

but have to deal with more pins on the connector

[dazz1]

Isn't USB C polarised ?

Not long ago, I would have said I don't know the answer.   
Now I know just enough to be certain I suffer from the Dunning-Kruger effect.  Therefore I can say with some confidence that the usb-C is polarised in a way that you can tell if the plug is in one way, or the other.  CC1 and CC2.

The attached image compares the connector datasheet pinout with my PCB layout.  The pin-out is asymmetric.  I was checking to see if I had made a mistake with the pcb layout. I hadn't. 

All of the diagnostics I have done point to a faulty connector.  I don't remember why I chose this connector, but I sourced it from Aliexpress, and that was probably a mistake.    Things like that happen under the effect of Dunning-Kruger. 

[dazz1]

I removed suspect usb connector and found the problem.  The visible side of the connector pins were nicely tinned.  The lower side was not. I also found lots of flux residue under the connector in a hard to clean out location.

I am replacing the usb-c connector and starting by tinning the lower side of the connectors.  There is no evidence the first connector was faulty.  Just bad soldering.  A little embarrassing  https://www.eevblog.com/forum/Smileys/default/facepalm.gif   because a few decades ago, I used to manage a school to train technician apprentices.  I introduced a High Reliability Hand Soldering course.  I never took the course myself so that is my excuse for making a mess of soldering the usb-c connector.

When I was young, my eyesight was good and I used large parts.  Now I am old, my eyesight is not so good, and I use really small parts.   

[tautech]

It does help to select extended/low density footprint when laying out the PCB which provide for a solder fillet to be formed rather than a footprint that's the perfect size for a component.
We all live and learn....

[dazz1]

I replaced the connector. 
Removed the solder bridges. 
Beeped out all the connector pins.

Connected everything up and ....  nothing.
The red led is doing what it should be doing, so the MCU is doing its thing. 

One of the usb data lines is floating so I could have 2x faulty usb cables or I have a bad batch of usb-c connectors. 

Since I stopped buying things of Aliexpress for the cheapest price, I haven't had an issue with quality.  I find the more you pay for an item on Aliexpress, the better the quality.  Definitely not true for western sellers.

Apart from the usb connector, there is no evidence that the fault is with the adapter, software etc. 

[dazz1]

I found the fault with my adapter today.
One of the 22R resistors in each USB data line between the MCU and the USB connector had an intermittent fault to open circuit.
I found the fault by rescuing a USB socket from an old motherboard.  This broke out all of the signal lines.
I was then able to do continuity checks through the cable, connector and to the various points on the pcb.  This test showed the connector is all good.
Probably should have found this fault earlier.

The adapter now reliable renumerates with both a Linux and Windows machines.

Now I am just tying to get a version of visa running following some pointers way back at post 102.

[coromonadalix]

Rhode Schwartz visa package is small and efficient, you have rs tools in it to send and read commands ...

[dazz1]

Rhode Schwartz visa package is small and efficient, you have rs tools in it to send and read commands ...

I have installed R&S visa, now I am just started reading through the manual to get it to work.  I have not used GPIB, visa or Python before.

[dazz1]

Finally, if you're familiar with Python, here is a simple script that can be used to read from the HP 3478A you mentioned in your earlier post. Please note: Your VISA resource string will be different because your adapter will have a different serial number to mine.

Code: [Select]

# HP 3478A Multimeter simple read test

import pyvisa

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

# Set function to DC volts
multimeter.write('F1')

try:
    while True:
        print(float(multimeter.read().strip()))
except KeyboardInterrupt:
    multimeter.clear()
    multimeter.close()
    rm.close()


Hi
where do I find the VISA resource string ?

[coromonadalix]

import pyvisa

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

[caiser01]

Hi
where do I find the VISA resource string ?

There's a couple ways to find it. Since you say you haven't used Python before, let's stick to R&S VISA for a start to keep things simple.

With your instrument connected to the PC with the USB->GPIB adapter, open the R&S Tester app (just called Tester on Windows, RsVisaTester on Mac/Linux). On the menu bar, click Find Resource. In the window that opens, click the big refresh button in the upper left corner. The available VISA resources will show up in the list on the right of that window. In the list, find the resource for your connected instrument ('USB0::0x03EB::0x2065::nnnnn::INSTR') and double click it. This will take you back the main window of the Tester app. From there, you can click the Connect button and try sending your instrument some commands. For the HP3478A, try writing F1, F2, F3, etc and observe whether the meter function is changing.

If everything looks good, just copy the VISA resource string from the Tester app window and paste it over the resource string in my example Python script. Close the Tester app and try running the Python script.

[dazz1]

There's a couple ways to find it. Since you say you haven't used Python before, let's stick to R&S VISA for a start to keep things simple.
...

I found the resource string using pyvisa on the command line.  I haven't tried R&S visa or your script yet.  Getting there.
I have been programming unprofessionally for around 45 years so I am reasonably relaxed about learning python.

Edit 17 Dec 2023:
A real resource string looks like this:

Code: [Select]

('USB0::0x03EB::0x2065::GPIB_02_24238323232351C01171::INSTR', 'ASRL1::INSTR')
                             ^^
It appears to be a constant that is unique to each adapter except for the GPIB instrument address.  In this case "02" marked with ^^.
If you have a list of instruments with their GPIB addresses, it should be possible to read the GPIB address from the resource string to figure out which code should run for that instrument.
This would avoid the need to identify specific adapters.  You would be able to plug in any adapter to any instrument. 

[caiser01]

It appears that the resource string is unique to each adapter (I have only assembled one so far).  If so, then the string should be physically readable on the adapter.
I haven't design the enclosure yet, but it would be easy to include a slot for a light card label with the printed resource string. 
It seems sensible to make the label big enough to include space for the ID of the test equipment that the associated software is written for.

The resource string will be different for each different instrument you use the adapter with.

If you have the adapter's Auto ID feature enabled (it is by default), the resource string will contain the instrument's response to a *IDN? query. For example, when connected to my HP 53131A universal counter, the resource string is: USB0::0x03EB::0x2065::HEWLETT-PACKARD_53131A_0_3703::INSTR

If you're connected to an instrument that does not support the *IDN? query or if you disable the adapter's Auto ID feature, the resource string will look like this:

USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR

The part in bold is a serial number that should be unique to each adapter. The GPIB_nn part represents the GPIB address of the connected instrument. This will change for different instruments with different addresses.

[dazz1]

Hi
I have been playing around with the code but it isn't working.  I don't appear to have comms with the meter. 

Code: [Select]

# HP 3478A Multimeter simple read test

import pyvisa

print("Simple GPIB test for HP3478A multimeter")
print("Show the list of Resources")
rm = pyvisa.ResourceManager()
print(rm.list_resources())
# ID string for adapter 0:  'USB0::0x03EB::0x2065::GPIB_23_24238323232351C01171::INSTR'

print("Opening the Meter")
# Resource = GPIB-usb adapter 0.  Different for each adapter.
multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_24238323232351C01171::INSTR')

# Write some text to display
multimeter.write('D2OK GPIB USB')

# Set function to DC volts (F1), auto-range (RA), trigger hold (T4), 4.5 digit (N4), auto-zero (Z1), internal trigger (T1)
multimeter.write('H1T1')
print("Reading the DC volts")
try:
    while True:
        print(float(multimeter.read().strip()))
except KeyboardInterrupt:
    multimeter.clear()
    multimeter.close()
    rm.close()
I usually add a lot of print statements to see what is working, and what isn't.
It isn't.
I get the following error messages:

Code: [Select]

>python gpib_test.py                                                                                     
Simple GPIB test for HP3478A multimeter                                                                                                                         
Show the list of Resources                                                                                                                                       
('USB0::0x03EB::0x2065::GPIB_23_24238323232351C01171::INSTR', 'ASRL1::INSTR')                                                                                   
Opening the Meter                                                                                                                                               
Traceback (most recent call last):                                                                                                                                 
File "D:\gpib_test.py", line 19, in <module>                                                                 
multimeter.write('H1T1')
...
If the resource string is from the instrument and not the adapter, then the adapter must have comms with the instrument.

The "D2" command just writes a string to  the display, but that is not happening.
The "H1T1" puts the meter into DC mode, continuous internal trigger, but it isn't. 
That indicates I may have a hardware fault either in the instrument, or in the adapter. 

R&S Tester does not find the usb-gpib adapter resource.  I am not sure if installing NI-visa or py-visa has over-written something that R&S needs.

[caiser01]

R&S Tester does not find the usb-gpib adapter resource.  I am not sure if installing NI-visa or py-visa has over-written something that R&S needs.

If you have multiple VISA implementations installed, we need to figure out which one pyvisa is grabbing.

What is the output when you run pyvisa-info from the command prompt?

[dazz1]

...
What is the output when you run pyvisa-info from the command prompt?

Code: [Select]

Machine Details:                                                                                                                                                   
Platform ID:    Windows-10-10.0.19045-SP0                                                                                                                       
Processor:      Intel64 Family 6 Model 94 Stepping 3, GenuineIntel                                                                                                                                                                                                                                                             Python:                                                                                                                                                             
Implementation: CPython                                                                                                                                         
Executable:     G:\Programs\Python310\python.exe                                                                                                                 
Version:        3.12.1                                                                                                                                           
Compiler:       MSC v.1937 64 bit (AMD64)                                                                                                                       
Architecture:   AMD64                                                                                                                                           
Build:          Dec  7 2023 22:03:25 (#tags/v3.12.1:2305ca5)                                                                                                     
Unicode:        UCS4                                                                                                                                                                                                                                                                                                           
PyVISA Version: 1.14.1                                                                                                                                                                                                                                                                                                            Backends:                                                                                                                                                           
ivi:                                                                                                                                                               
Version: 1.14.1 (bundled with PyVISA)                                                                                                                           
#1: C:\WINDOWS\system32\visa32.dll:                                                                                                                                 
found by: auto                                                                                                                                                   
architecture:                                                                                                                                                       
('x86', 64)                                                                                                                                                   
Vendor: Rohde & Schwarz GmbH                                                                                                                                     
Impl. Version: 7340546                                                                                                                                           
Spec. Version: 7340544                                                                                                                                       
#2: C:\WINDOWS\system32\visa64.dll:                                                                                                                                 
found by: auto                                                                                                                                                   
architecture:                                                                                                                                                       
('x86', 64)                                                                                                                                                   
Vendor: Rohde & Schwarz GmbH                                                                                                                                     
Impl. Version: 7340546                                                                                                                                           
Spec. Version: 7340544                                                                                                                                                                         

I can see it is grabbing the R&S visa (I have NI visa installed as well) but when I run R&S directly, it does not detect the usb-gpib adapter. 
So I still don't know if I have a HW or SW fault.

I am writing a test program in C++ (another new language to me, although I have programmed in C-like languages eg.Java) that will sequentially pulse each port pin.  It will help identify solder bridges or open circuits on the port pins.
It will be a separate stand-alone program usable on, or adaptable to, any AVR MCU.

[caiser01]

I can see it is grabbing the R&S visa (I have NI visa installed as well) but when I run R&S directly, it does not detect the usb-gpib adapter.

That's weird given that when you run the Python script, it does detect the adapter.

Just for giggles, try adding this line after the open_resource line:

Code: [Select]

multimeter.write_termination = '\n'
If that doesn't work, try making it '\r\n'.

[dazz1]

Just for giggles, try adding this line after the open_resource line:

Code: [Select]

multimeter.write_termination = '\n'

That worked. Thanks.

The code displayed:

Code: [Select]

>python gpib_test_HP3478A.py                                                                             
Simple GPIB test for HP3478A multimeter                                                                                                                         
Show the list of Resources                                                                                                                                       
('USB0::0x03EB::0x2065::GPIB_23_24238323232351C01171::INSTR', 'ASRL1::INSTR')                                                                                   
Opening the Meter                                                                                                                                               
Reading the DC volts                                                                                                                                             
-1.6431                                                                                                                                                         
-1.6427                                                                                                                                                         
-1.6425                                                                                                                                                         
...

So that confirms the adapter is 100% working. 

[caiser01]

So that confirms the adapter is 100% working. 

Took a while to get here but that's great!

Just had a look at xyphro's GitHub and it sounds as if he's been busy optimizing the firmware. Should be a nice update when he does his next release.

[dazz1]

Just had a look at xyphro's GitHub and it sounds as if he's been busy optimizing the firmware. Should be a nice update when he does his next release.

This adapter is a software project with some hardware attached.  The quality of this type of project is largely defined by the software.  Optimizing the software can only be a good thing.
There might be an improvement to be gained by simply altering the compiler settings.  By default, the MAKE file compiler settings are set to create the smallest firmware file size.  Also the slowest to execute.  Changing compiler setting to increase the file size should be a zero effort action to make a small increase in speed. 

When the compiler is set to build a large file, it replaces call to functions with the code of the function.  Code is repeated.  It is very inefficient on code size, but also fast.  There is no reason to keep the file size any smaller than 32k on the ATmega32U. 

[dazz1]

So that confirms the adapter is 100% working. 

Took a while to get here but that's great!

Now I am working on using the GPIB for my WaveTek 2520 RF Signal Generator.  I have GPIB comms so the instrument is OK but I need to figure things out to get all the commands working. 
At present, I am using my deck top PC, which is no where near my workshop.

I would like to get my little old Linux Asus eeePC running pyvisa.  What do you suggest, and in what order should I install?  NI, R&S ?

[alm]

I would like to get my little old Linux Asus eeePC running pyvisa.  What do you suggest, and in what order should I install?  NI, R&S ?

I found installing a commercial VISA stack a pain on Linux. Especially maintaining it through OS upgrades. I'd also research what hardware they support. I know NI-VISA doesn't support NI GPIB-USB devices on Linux kernel versions from the last 15 years or so. I don't know about USBTMC.

I would use PyVISA-py as backend. This integrates much better with Linux and doesn't require any kernel modules or daemons to run.

[caiser01]

I would like to get my little old Linux Asus eeePC running pyvisa.  What do you suggest, and in what order should I install?  NI, R&S ?

I found installing a commercial VISA stack a pain on Linux. Especially maintaining it through OS upgrades. I'd also research what hardware they support. I know NI-VISA doesn't support NI GPIB-USB devices on Linux kernel versions from the last 15 years or so. I don't know about USBTMC.

I would use PyVISA-py as backend. This integrates much better with Linux and doesn't require any kernel modules or daemons to run.

I've been running R&S VISA on Linux on the Raspberry Pi with zero issues. Like the Windows version, the Linux version of R&S VISA is small, lightweight, and doesn't drag you into any sort of package dependency hell. The only quirk I've encountered is needing to explicitly reference the R&S VISA library in my Python scripts in order to keep pyvisa from automatically wanting to grab pyvisa-py as the backend, but it's pretty easy. I just have this at the top of all my Python scripts for GPIB:

Code: [Select]

from sys import platform

if platform == "linux" or platform == "linux2":
    # Linux
    rm = pyvisa.ResourceManager("/usr/lib/librsvisa.so@ivi")
elif platform == "darwin":
    # macOS
    rm = pyvisa.ResourceManager("/Library/Frameworks/RsVisa.framework/RsVisa@ivi")
elif platform == "win32":
    # Windows
    rm = pyvisa.ResourceManager()

[alm]

What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?

[dazz1]

What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?

I had a look at your launchpad page.  I see you are maintaining GPIB firmware, kernel and user packages.
Can you please explain what each package is for (the use cases?)

[alm]

I had a look at your launchpad page.  I see you are maintaining GPIB firmware, kernel and user packages.
Can you please explain what each package is for (the use cases?)

That isn't necessary to use with the adapter discussed in this topic, which uses USBTMC. As you can read in the PyVISA-py documentation, it just needs libusb for this.

The packages in my signature is for with commercial USB and PCI(e) GPIB interfaces like those made by Agilent, Keysight, NI etc. Also clones, as far as I know. There are kernel drivers, the user space libraries so native (C) applications can talk to them, and Python bindings so Python can talk to them. These packages would allow you to use for example an NI GPIB-USB-HS interface with PyVISA-py.

[dazz1]

I had a look at your launchpad page.  I see you are maintaining GPIB firmware, kernel and user packages.
Can you please explain what each package is for (the use cases?)

That isn't necessary to use with the adapter discussed in this topic, which uses USBTMC. As you can read in the PyVISA-py documentation, it just needs libusb for this.

The packages in my signature is for with commercial USB and PCI(e) GPIB interfaces like those made by Agilent, Keysight, NI etc. Also clones, as far as I know. There are kernel drivers, the user space libraries so native (C) applications can talk to them, and Python bindings so Python can talk to them. These packages would allow you to use for example an NI GPIB-USB-HS interface with PyVISA-py.

OK so I should just follow the instructions for PyVISA-py.

[caiser01]

What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?

The xyphro adapter presents itself to PC as a USB device and in PyVISA-py, there are several VISA functions that are not implemented for USB. These include clear(), read_stb(), and assert_trigger() all of which can be necessary to take full advantage of an instrument's remote programming capabilities. read_stb(), assert_trigger(), and the various "event" functions in particular are often necessary to get the fastest possible communication with an instrument.

To install R&S VISA on the Pi on Linux, all I had to do was download it and run:

Code: [Select]

sudo dpkg -i rsvisa_5.12.9_raspios_buster_arm64.deb
Running the installer on Windows or Mac is pretty quick too, so I would argue the setup effort is minimal.

R&S VISA also provides the Tracer app, which is super handy for debugging. Just open it and start monitoring in the background while your own application is communicating with the instrument, and you can watch all the raw traffic between your application and the instrument. Great way to track down issues in your GPIB command sequences, especially for the quirkier instruments.

[Nx-1997]

Well I finally decided to benchmark my GPIB adpaters since Xyphro released a new firmware. The results shows the capture time (s) for reading a waveform from my tek scope. The new firmware is much faster but not as fast as the Agilent 82357B. The AR488 is the slowest but also the only one not requiring any special drivers or software.

Full results discussion are here: https://github.com/xyphro/UsbGpib/discussions/47

[caiser01]

I tested xyphro's new release candidate firmware today. Very solid so far. My instruments are old and slow enough that I'm not really seeing the improvements in read/write speed for data but I *did* see a speed improvement in reading the status byte. Reading the status byte of my HP3478A is 250ms faster with the new firmware than the old firmware 

[dazz1]

Hi
I have started to learn Python and Py VISA to write code to run my mostly ancient instruments with GPIB.  I have already hit problems writing code that I am sure others have already solved.  I have started a new thread here:
https://www.eevblog.com/forum/projects/problems-writing-code-for-gpib-py-visa/new/#new as a sort of mini-forum.

[coromonadalix]

I tested xyphro's new release candidate firmware today. Very solid so far. My instruments are old and slow enough that I'm not really seeing the improvements in read/write speed for data but I *did* see a speed improvement in reading the status byte. Reading the status byte of my HP3478A is 250ms faster with the new firmware than the old firmware 

at :  https://github.com/xyphro/UsbGpib

[dazz1]

Hi
Just a tip.
I spent the day assembling 4x usb-gpib adapter. 
My first adapter assembled a few weeks ago had problems with bad joints and solder bridges.  I blame it all on the cat.

This time I pre-tinned the pins for the usb-c connector and the matching pads.
I also pre-tinned the QFN pads and pcb pads.

I smeared solder across the earth/heat pad on the QFN.

This left a Goldilocks amount of solder for the joints.  All good joints and no excess solder to clean away.  The cat is sleeping peacefully.

[dazz1]

Hi
A question for those with experience debugging gpib.  Is it still useful to have a breakout board to read the gpib signals??

The reason I ask is because I have HP54645D scope with 16 channel digital logic inputs like this one  https://metalab.at/wiki/Datei:HP54645D.jpg.  If I make a gipb breakout board, I can plug the flat cable into the scope and board.  No fiddly probes.
The same board could be used with a HP logic analyser because they use the same cable.

[pdenisowski]

Hi
A question for those with experience debugging gpib.  Is it still useful to have a breakout board to read the gpib signals??

I just bought a commercially made GPIB breakout board.  Am planning to use it this week to debug / analyze some GPIB traffic.

https://tinyurl.com/2s499tar

(Sorry, tried to post link to the pics here on EEVblog and it keeps failing, so posting a shortened link)

[Kean]

Can certainly be useful if you need to diagnose weird GPIB issues or debugging your own interface
I made up one of these by Jason aka cellularmitosis

https://github.com/pepaslabs/gpib-spy

[dazz1]

Hi
Well it looks like I will be making a break out board, but not like either of the linked designs.

I will make use of the connectors I have in the photo.
I got the Centronics gpib connectors from Aliexpress because they are dirt cheap.  I purchased the HP logic analyser compatible connector to see if it would fit.  It does, that gave me a solution looking for a problem.
I will design a board that will connect directly to an HP logic analyser, that I don't have, or my HP 54645D mixed signal scope that I do have.
The logic probes designated for the HP54xxx series scopes have the probes integrated with the flat cable.  They are rare an expensive. 
I purchased the cable  and probe set that plug together. Easier to find, cheaper and more versatile.

Along with the Centronics connectors, and HP compatible connector I will include pads for a separate header to make it easy to probe individual lines, if ever needed. Probably a feature I would never use but extra pads are a zero cost. 

I will be able to save a configuration in the scope, and just plug and play the break-out board.  The board will still be usable for someone without a logic analyser. 

[dazz1]

Hi
Looking at the detail of the gpib cable standard to apply to my breakout board, the pin-out includes a shield ground plus signal grounds.
My question is: Should the shield ground be connected to the signal grounds?

The  IEEE 488.1 mechanical specification costs a $squillion ( = $USD391.00) so not looking there.

[caiser01]

Hi
Looking at the detail of the gpib cable standard to apply to my breakout board, the pin-out includes a shield ground plus signal grounds.
My question is: Should the shield ground be connected to the signal grounds?

The  IEEE 488.1 mechanical specification costs a $squillion ( = $USD391.00) so not looking there.

I do have access to a copy of IEEE 488.1 and regarding grounding, it says:

5.6 Ground requirements
The overall shield of the interconnecting cable shall be connected through one contact of the connector to frame (safety earth) to minimize susceptibility to and generation of external noise.

WARNING—Devices should not be operated at significantly different frame potentials. The interface connection system may not be capable of handling excessive ground currents.

It is recommended that the ground returns of the individual control and status signal lines be connected to logic ground at the logic circuit driver or receiver to minimize cross-talk interference transients.

Based on that, I would answer your question with a 'No'. It sounds like the intent is to connect the cable shield to the safety earth ground of an instrument or controller (assuming it has a safety earth ground).

In your case, since this is a breakout board for debugging purposes and is essentially passive, like a cable, I would say just make sure the shield ground connects through the breakout from one GPIB connector to another. Do not permanently connect any grounds together on the breakout that would normally run separately inside a cable.

[caiser01]

For completeness, it may also be worth noting the maximum resistance per meter for each conductor and insuring the design of your breakout doesn't cause a violation of these requirements:

5.7 Cable characteristics

5.7.1 Conductor requirements

The maximum resistance for the cable conductors shall be, per meter of length
a) Each signal line (for example, DIO1, ATN) 0.14 Ω
b) Each individual signal line ground return 0.14 Ω
c) Common logic ground return 0.085 Ω
d) Overall shield 0.0085 Ω

[dazz1]

Based on that, I would answer your question with a 'No'. It sounds like the intent is to connect the cable shield to the safety earth ground of an instrument or controller (assuming it has a safety earth ground).

In your case, since this is a breakout board for debugging purposes and is essentially passive, like a cable, I would say just make sure the shield ground connects through the breakout from one GPIB connector to another. Do not permanently connect any grounds together on the breakout that would normally run separately inside a cable.

The board by itself is passive, but it will be connected to the logic analyser I don't have, or my HP 54654D logic input. I am including a header that will allow the cable to be plugged into the board, no probes.  The probe adapter for the cable has one earth.  So I can separately route all of the individual earths that are supposed to be separate in the cable, but I still need an earth for the scope.   The most logical gnd being the Logic gnd at pin 24.  Does that sound right? 

[dazz1]

After a little more thought:
The intended use is to plug-in directly to the subject equipment.  It is very likely that the equipment will have all earths connected.  Repeating that connection at the gpib panel connector is probably not going to be enough of an issue to stop the breakout board doing the job it needs to do.

Also I suspect the average 1980's/90's engineer would not have paid for the standard and would likely simply connected all of the earths together.  The exception might be the shield.  Somewhere I read this should be linked to the other earths by a 1M resistor.   Maybe to keep the dc floating volts within reasonable limits but that is not a convincing argument.

I could include a DIL2x8 header to selectively link earths to a main ground but it would actually be less work to produce a new Mod 2 pcb design. 
So the plan is to connect all the grounds together, except the shield.  I will run that straight through with a Fit-For-But-Not-With option for a smd resistor, just in case. 
If there is a problem, I will design a new pcb.

[pdenisowski]

Also I suspect the average 1980's/90's engineer would not have paid for the standard and would likely simply connected all of the earths together. 

The average engineer working in test and measurement in the 1980s/1990s would either (a) have bought commercial off-the-shelf GPIB adapters and cables and not needed the spec, or (b) would have the spec if they were actually developing GPIB devices.  Ask me how I know

That said, I think this is a fantastic project and am very excited to see how it turns out.  Thank you for doing this!

[dazz1]

Hi
Given where you work, I would have thought the developers already have breakout boards.
Anyway, attached are my drafts. 

Unlike other breakout bds I have seen, my one has a connector that conforms to the HP pseudo standard 40pin Logic Analyser cable. This board will plug directly to my HP scope  that I have, or any HP LA I don't own.  No messing around with probes.

The board will be self documenting.  I am going to add text to the lower silkscreen to show the 40 pin connector signals.  Already done that for the header. 

The header has the same pin-out but exposes the signals and allows for jumpers to be fitted.  Specifically, one use case would be to connect a control signal to the LA CLK.  It also means that someone who does not have a suitable LA type instrument can probe the signals with this board.

I am interested in any feedback to improve the design.

[pdenisowski]

I am interested in any feedback to improve the design.

Frankly, I like it just the way it is - a big improvement over what I've seen so far for GPIB breakout boxes.

[dazz1]

Hi
I have polished the design. 
Getting pcb's made and buying parts with MOQ's means I will end up with 5 of these, when I only need one.

[Kean]

I believe the intent was that pin 12 should be connected to the cable shield (chassis ground) and not to logic ground.
Pin 24 is the primary logic ground, and pins 18-23 are nominally logic ground but are actually specified as paired with the signal on the pin above (6-11).

Practically all devices I've seen connect pins 18-24 together, and only some also include pin 12 connecting the this common ground.
As an example, schematics of Keithley 199 have pin 12 connecting to chassis, and there is a 1M resistor and 10n capacitor between chassis and logic ground (with optional jumper).

I doubt any of this will make much difference except with very long cables and multiple instruments.

[dazz1]

Hi
OK I have made those changes.
I should add a cap to the second gpib connector but that would mess up my text layout. 
I don't intend fitting the C/R, unless I have to.

[Kean]

I don't intend fitting the C/R, unless I have to.

Nope, C/R not really needed.  Just leave shield connection intact through the cable and keep it separate from logic ground, and obviously use the logic ground for the LA/scope connection.
It doesn't hurt to have the 1M resistor between shield and ground as you have it, but that may also already exist in one of your other devices on the bus.

If you have extra PCBs/connectors than I'd be happy to contribute some $ towards one or two and the cost of postage to Sydney.
I have a bunch of GPIB/HPIB gear in the office lab and at my home, spread across several benches, and with some still needing repairs.

[dazz1]

If you have extra PCBs/connectors than I'd be happy to contribute some $ towards one or two and the cost of postage to Sydney.

I was planning on selling the spare ones on the local auction website.  I know  there are a few people watching my blog posts.  It will be easy enough to send one over the water. 

I am also looking at putting the pcb design into pcbway projects.  Mine would be the only project on pcbway that includes "gpib" so I am probably about 30 years late in designing a break out board.

I try and do pcbs in batches to reduce shipping costs. I may be a while before I am ready to get them made. 

[dazz1]

Hi
OK I have settled on a final version of the gpib breakout board.

The most significant change is the addition of notches that are almost mounting holes.
I usually include mounting holes, but I think if anyone makes one of these, they are unlikely to make an enclosure.
If they want to 3D print an enclosure, they can include keys in the print to match the notches, or
they can use M3 screws.

I have refined the text on the silk screen to make it easier to use.  It should not be necessary to refer to standards or pinouts to use this board.

[tautech]

Test is it ?
Unconnected NET pin 1 J3. 

[dazz1]

Test is it ?
Unconnected NET pin 1 J3. 

No not quite.  The pcb is correct.  That pin, and the one on the other header are "V" on the HP logic analyser 40 pin pseudo standard.  "V" is not connected on my scope.  So this connection would only be active if a HP LA was connected, and the other header was connected to something that needed "V". That is extremely unlikely but it didn't cost anything to add the track, and the other LA signals not used by the scope.  So all good.

Also pin 5 is NC on the HP standard.

Edit: On closer inspection, the line indicates the "J3" label is linked to the connector, because I had selected the J3 label.  So no problem but well spotted.

[tautech]

Test is it ?
Unconnected NET pin 1 J3. 

No not quite.  The pcb is correct.  That pin, and the one on the other header are "V" on the HP logic analyser 40 pin pseudo standard.  "V" is not connected on my scope.  So this connection would only be active if a HP LA was connected, and the other header was connected to something that needed "V". That is extremely unlikely but it didn't cost anything to add the track, and the other LA signals not used by the scope.  So all good.

Also pin 5 is NC on the HP standard.

Edit: On closer inspection, the line indicates the "J3" label is linked to the connector, because I had selected the J3 label.  So no problem but well spotted.

Not what I spotted.....the little arrow on the Pin 1 trace that the ratsnest link connects to.
I believe with your editor this indicates a not fully terminated NET.

[dazz1]

Not what I spotted.....the little arrow on the Pin 1 trace that the ratsnest link connects to.
I believe with your editor this indicates a not fully terminated NET.

It's a warning about pin 1 pad attributes not matching the symbol.  Not an open net and not a problem.

[dazz1]

Hi
I have shared my GPIB breakout board on PCBway here:
https://www.pcbway.com/project/shareproject/GPIB_Break_Out_Board_f7812b3e.html

I have order parts for 5x boards, because of MOQ's so I will have 4x for sale.

[dazz1]

Hi
I have shared my GPIB breakout board on PCBway here:
https://www.pcbway.com/project/shareproject/GPIB_Break_Out_Board_f7812b3e.html

I have order parts for 5x boards, because of MOQ's so I will have 4x for sale.

Hi
I have made the first GPIB breakout board and updated the pcbway share project, available for ordering your own board.
I now have 4x spare boards and parts available for sale.  Cheaper than buying parts and boards for one, like I have done.
As you can see, it plugs directly into the HP Logic Analyser cable.  It would be easy to make up a cable to adapt the GPIB breakout connector to another make/model of LA.
In addition, the signals are also exposed on a separate header.