open source GPIB adapter

[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.