Products > Test Equipment
open source GPIB adapter
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:
--- Quote from: dazz1 on November 18, 2023, 04:10:30 am ---
--- Quote from: caiser01 on November 17, 2023, 05:11:11 pm ---Okay, I combined the two original hex files from xyphro's repository with this command:
--- Code: ---srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o UsbGpib-combined.hex -Intel
--- End code ---
Then I programmed that combined hex file to one of my five working adapter of xyphro's hardware design using this command:
--- Code: ---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
--- End code ---
So the hex file attached below when flashed to the hardware I have results in a working UsbGpib adapter.
--- End quote ---
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.
--- End quote ---
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: ---..\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
--- End code ---
and 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: --->lsusb
--- End code ---
The adapter did not show (as expected).
When I then connected the adapter to my HP 3478A, and ran
--- Code: --->lsusb
--- End code ---
again, no show.
I have an issue with the USB. I have swapped cables with no change.
caiser01:
--- Quote from: dazz1 on November 25, 2023, 04:14:08 am ---
--- Code: ---..\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
--- End code ---
--- End quote ---
Running your command above to program one of my known good boards still results in a fully working adapter for me.
--- Quote from: dazz1 on November 25, 2023, 04:14:08 am ---I have an issue with the USB.
--- End quote ---
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:
--- Quote from: alan.bain on November 22, 2023, 11:52:01 am ---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.
--- End quote ---
I discovered the MQTT protocol today. At first glance it could be applied to GPIB networked comms.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version