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....
My PCB is OK. Pin 1 marked on the connector puts it on the bottom left.
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'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
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
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.
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.
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
avrdude -P usb -c usbasp -p m32u4 -e -U flash: "FLASH.BIN" -vvvv/etc/avrdude.conf
and man avrdude
or/and cp TestAndMeasurement.bin /run/media/baettig/GPIBUSBBOOT/FLASH.BIN
# verify with md5sum, umount, unplugI 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
On Linux, there is a bug with the LUFA mass storage that means it is required to useCode: [Select]dd if=TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync
Did you see the note re. Linux on the README ?
Code: [Select]dd if=TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync
GPIBUSBBOOT(D:)
EEPROM.BIN 1KB
FLASH.BIN 24KB
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
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)
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
>$ avrdude -P usb -c usbasp -p m32u4 -e -U flash:w:FLASH.BIN
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.
#!/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"