Products > Test Equipment
open source GPIB adapter
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:
--- Quote from: dazz1 on November 15, 2023, 02:16:32 am ---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.
--- End quote ---
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:
--- Quote from: caiser01 ---
I think I understand what you're getting at; a sort of "factory test" of the GPIB adapter.
--- End quote ---
Yes, that is exactly what I would have done if I developed this project.
--- Quote from: caiser01 --- If the virtual USB drive part worked for flashing then you've already confirmed USB is working.
--- End quote ---
After doing some testing today, I am less confident the USB drive part is working. Hmmmm.
--- Quote from: caiser01 ---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.
--- End quote ---
Yes.
--- Quote from: caiser01 --- 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.
--- End quote ---
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.
--- Quote from: caiser01 ---
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.
--- End quote ---
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.
--- Quote from: caiser01 ---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.
--- End quote ---
Yes. I am running Xyphro's firmware as-is, without modification.
--- Quote from: caiser01 ---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.
--- End quote ---
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:
--- Quote from: dazz1 on November 15, 2023, 04:49:45 am ---From the windows side, using a USB-ASP programmer, I cleared FLASH and burned the bootloader.
--- End quote ---
What commands did you use to do this?
dazz1:
--- Quote from: caiser01 ---What commands did you use to do this?
--- End quote ---
I followed the Xyphro instructions with these commands:
--- Code: ---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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version