I didn't do what you said. I tried something else.
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.
# 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 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()
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.
srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o combined.hex -Intel
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.
From the windows side, using a USB-ASP programmer, I cleared FLASH and burned the bootloader.
What commands did you use to do this?
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
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
avrdude -c usbasp -p m32u4 -U flash:w:TestAndMeasurement.hex
Then I get the flashing LED back again.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 (;;);
}
srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o UsbGpib-combined.hex -Intel
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
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.
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.
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.
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.
..\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
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.>lsusb
The adapter did not show (as expected).>lsusb
again, no show.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
I have an issue with the USB.
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.