open source GPIB adapter

[dazz1]

Hi
I may have found the bug mentioned in the README file.
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.

[dazz1]

I found some ready-made GPIB control software here:
https://www.eevblog.com/forum/testgear/hp-34401a-standalone-software/
I just need to get my adapter working first.

With the usb interface malfunctioning, I can't over-write the existing software via the usb connection.  I will have to do it with avrdude. 

[caiser01]

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()


[dazz1]

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()


I agree with all of the above but I generally don't learn a lot by just following the instructions.  I want to modify the Xyphro software to run on my hardware, while remaining compatible with the Xyphro version.    To do that I need a deeper understanding of programming model and tool chain.  I have programmed in a number of languages but not Python or C++ so I intend to learn.    Before this project, I had never heard of avrdude but now I can write usable commands.

I will use those links to the gpib type software.  They will be useful as a confidence check and for diagnostics.

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.  When first plugged in, the adapter would not appear as a memory device.

I have avrdude installed on the windows side so I am going to play around with that.  If things get truly desperate,  I might even be forced to follow the instructions. 

[caiser01]

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.

If you want a single hex file that combines the bootloader and GPIB application, there's another way that might be easier. Go get SRecord (https://srecord.sourceforge.net/) and use srec_cat to concatenate the hex files for the bootloader and the application. Both hex files are available already compiled in xyphro's repository. The command to concatenate them will look similar to this:

Code: [Select]

srec_cat BootloaderMassStorage.hex -Intel TestAndMeasurement.hex -Intel -o combined.hex -Intel
That should give you a single hex file you can flash with avrdude in one step.

I would still encourage you to flash one adapter by the original instructions so you have a known good baseline before you start changing things.

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

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.

[dazz1]

I think I understand what you're getting at; a sort of "factory test" of the GPIB adapter. 

Yes, that is exactly what I would have done if I developed this project.

  If the virtual USB drive part worked for flashing then you've already confirmed USB is working.   

 
After doing some testing today, I am less confident the USB drive part is working.   Hmmmm.

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.   

 
Yes. 

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.   

 
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. 

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.   

 
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.

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. 

 
Yes.  I am running Xyphro's firmware as-is, without modification.

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.

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]

From the windows side, using a USB-ASP programmer, I cleared FLASH and burned the bootloader.

What commands did you use to do this?

[dazz1]

What commands did you use to do this?

I followed the Xyphro instructions with these commands:

Code: [Select]

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

[caiser01]

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

[dazz1]

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

Yes, but I am no longer seeing a usb  connection on my PC regardless of what I do.  At present the adapter is plugged into a gpib device (HP 3478A), the LED is flashing, but the PC does not see the usb adapter.  I am working to the hypothesis that there is a hardware fault on the usb section.   The first step is to concat the bootloader and TestAndMeasurement files to see if I can get the adapter to present itself as a CD-ROM.

[alan.bain]

I have a little direct adaptor Ethernet to GPIB built around a STM32 F439ZI Nucleo and a small daughter board with bus transceivers (so it can operate multiple devices). It seems to work well and at some point I produced a PCB with the whole lot on it to avoid needing the Nucleo, must test someday (the prototype worked well enough it just got used).

It speaks a Prologix like command set and seems featured enough to run an HP3048 type phase noise setup.  It doesn't support parallel poll because I didn't need it and never wrote the software although the hardware should support it.

It's very convenient as the whole equipment rack is connected to ethernet and can happily be controlled by any wifi device without lots of USB wires to risk pulling off surface mount USB micro sockets!

(Happy to share the firmware source code / put in public domain for others to use)

[dazz1]

I have taken a closer look at the HEX files.  I think they already include the correct memory address locations.  It should be possible to load both with them ending up in the right locations in flash.
So from the windows side, I ran the avrdude command shown in the attached screen snip.

The response indicated successful programming.  When I plugged the adapter into the PC usb port, nothing.  No flashing LED, no ding from the PC to indicate a USB connection.  The later may be the usb hardware fault. 

When I run the the avrdude command that only programs the TestAndMeasurement.hex and not the BootLoasder.hex

Code: [Select]

avrdude -c usbasp -p m32u4 -U flash:w:TestAndMeasurement.hexThen I get the flashing LED back again.

It would be useful to know if both hex files can be programmed and then run on hardware known to be working.  If both hex files can be programmed with one command, that would simplify things.
The software includes a magic value which I think triggers the call to the BootLoader at address 0700h by enabling the watch dog timer, but I haven't studied this in detail.

Code: [Select]

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 (;;);
}
The next thing I will do is some troubleshooting of the USB hardware to see if I can find something.

[caiser01]

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
Right away the LED started flashing. I shorted the two pins on the programming header and the virtual USB drive appeared on my PC as expected. Unplugged and replugged the USB cable and then connected the adapter to my HP 5385A frequency counter. The USBTMC device became visible and then I was able to talk to the counter interactively from Python.

So the hex file attached below when flashed to the hardware I have results in a working UsbGpib adapter.

[dazz1]

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.

[alan.bain]

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.

[caiser01]

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.

Nice design! I'd be interested to see the source code if/when you want to share. Might be interesting to see about porting to a lower pin count version of the STM32F4 for easier assembly. Still this is very cool!

[alan.bain]

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.

[caiser01]

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.

You mentioned your adapter uses a command set like the Prologix and AR488. How do you interface with it from the PC? Is there an embedded web page? Or is a TCP/IP socket sort of thing?

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

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.

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: [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.hexand 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: [Select]

>lsusb The adapter did not show (as expected).
When I then connected the adapter to my HP 3478A, and ran

Code: [Select]

>lsusb again, no show.

I have an issue with the USB.  I have swapped cables with no change. 

[caiser01]

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

Running your command above to program one of my known good boards still results in a fully working adapter for me.

I have an issue with the USB.

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]

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.

I discovered the MQTT protocol today.  At first glance it could be applied to GPIB networked comms.