AR488 Arduino-based GPIB adapter

[artag]

@mlefe :

Did you modify it inline for the blue pill or isolate the register access
?

I did a 32u4 port of an earlier version of the code but never got around to testing it. When I redo it I'd prefer to break the hardware-specific parts out into macros so they can be swapped easily, but if someone else already did that I'd rather build on their work.

[mlefe]

Well, the good news is that I've talked too soon: I put together Emanuele's version on an Arduino UNO and I'm able to communicate with my devices again...
SO... back to troubleshooting the STM32 version.
@rhb, I believe the 3.3V should be fine because when I was testing my 34401a I've realised that it's using 3V for the HIGH (it uses a 75ALS162 as driver: it receives 5V internally but puts around 3V in the GPIB port).
I'll let you guys know if I make any progress.

[mlefe]

@mlefe :

Did you modify it inline for the blue pill or isolate the register access
?

I did a 32u4 port of an earlier version of the code but never got around to testing it. When I redo it I'd prefer to break the hardware-specific parts out into macros so they can be swapped easily, but if someone else already did that I'd rather build on their work.

I've used #define to isolate the code and not disturb the original one in an attempt to not disrupt it while rewriting some of the necessary functions that used the registers and pins.
I can share my code, but at this point is really ugly and doesn't work...

[rhb]

Well, the good news is that I've talked too soon: I put together Emanuele's version on an Arduino UNO and I'm able to communicate with my devices again...
SO... back to troubleshooting the STM32 version.
@rhb, I believe the 3.3V should be fine because when I was testing my 34401a I've realised that it's using 3V for the HIGH (it uses a 75ALS162 as driver: it receives 5V internally but puts around 3V in the GPIB port).
I'll let you guys know if I make any progress.

Please read "The TTL Cookbook", p 10 available from the author at no cost at tinaja.com.

Put a 1k resistor in series with the STM32 pin, drive the pin high and measure the voltage at the pin.  For it to be reliable that voltage *must* be significantly more than 2.0 V.  TTL logic by design provides a 1.3 V noise margin.  The 3 mA per pin per device GPIB spec was not made up just because someone wanted to do that.  It was because it reflects the reality of driving 5 V TTL logic gates on the end of a long cable.  Where any stray signal pickup can shift the voltage up or down by a few tenths.

The worst possible outcome is you get your 34401A to function at 2.1 V and a lot of other people find that theirs won't work reliably.  For which all the blame will be yours for ignoring basic digital electronics requirements.

It's easy to dismiss "The TTL Cookbook" as obsolete and irrelevant, but nothing could be farther from the truth.  Don discusses the device level physics and those don't change.  The same diode drops apply.  The only thing that has changed is the noise margins are a *lot* narrower.  Which is why I have fixed a good bit of 3.3 V logic consumer electronics simply by cleaning the residual solder flux off the board.

[artag]

How are you programming the blue pill ?

I have some here but haven't really got a usable workflow for them. But I have got a logic analyser and even one of those old HPIB analysers bitseeker mentions.



(very puzzled as to why I was entering a newline every time I hit '?'. Thought it was the forum software but it was because of a bit of hot glue that had fallen between the shift and return keys ...)

[artag]

rhb,

From table 36 (output driving characteristic) on page 65 of the STMF103 datasheet, we get :

With 8mA pin drive, Vdd 2.7-3.6 V

Output low level for a CMOS port I/O pin when 8 pins are sunk at the same time, max 0.4V
Output high level for a CMOS port I/O pin when 8 pins are sourced at the same time, min Vdd -0.4
Output low level for a TTL port I/O pin when 8 pins are sunk at the same time, max 0.4V
Output high level for a TTL port I/O pin when 8 pins are sourced at the same time, min 2.4V

which seems OK. But at 20mA per pin, Voh is only 1.3V (or VDD-1.3 for CMOS) which is too low.

So I'd think it was OK for 2 loads and possibly 3 (unspecified, but there's a good margin at 2 loads) but not for 6 or 7.

I'm not really sure why they specify CMOS and TTL ports as though they're something different. As far as I can tell those figures apply to all ports except for 3 specific pins which have a 3mA limit. The CMOS/TTL designation just seems to be to distinguish the spec of 2.4V for TTL and Vdd - 0.4 for CMOS. Vdd - 0.4 would still give at least 2.4V out down to a supply of 2.8V but spec says its maintained to 2.7V Vdd. At 3.3V and 8mA it should be at least 2.9V.

[mlefe]

How are you programming the blue pill ?

I have some here but haven't really got a usable workflow for them. But I have got a logic analyser and even one of those old HPIB analysers bitseeker mentions.



(very puzzled as to why I was entering a newline every time I hit '?'. Thought it was the forum software but it was because of a bit of hot glue that had fallen between the shift and return keys ...)

Everytime I receive a new one, I perform these steps to install the firmware from stm32duino:
1. I connect a FTDI to the blue pill
2. I move the "upper" jumper to 1
3. I connect the FTDI to a USB port. I verify that it appears as "Prolific USB To Serial Port (COM 6)" (6 or whatever other port)
      If this step fails, I download PL2303_64bit_Installer that installs version 3.8.18.0 (this one works for Win10)
4. Then I go to "C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win"
5. I then execute this line: stm32flash.exe -w ..\..\STM32F1\binario\generic_boot20_pc13.bin COM6 (6 is an example, you should use the previous port)
6. I shift the upper jumper back to "0"

Then I use the arduino IDE with the following settings (in the "Tools" menu):
Board: Generic STM32103C
Variant: STM32F103CB (20k RAM, 128K Flash)
CPU Speed: 72MHz
Upload Method: STM32duino Bootloader

Sometimes when I'm uploading the sketch it gets stuck waiting for the DFU interface, if that happens I quickly reset it (so it starts in DFU mode) and that's enough to make it work.

If you have any doubt on the steps or the files needed let me know

[rhb]

So I'd think it was OK for 2 loads and possibly 3 (unspecified, but there's a good margin at 2 loads) but not for 6 or 7.

I'm not really sure why they specify CMOS and TTL ports as though they're something different. As far as I can tell those figures apply to all ports except for 3 specific pins which have a 3mA limit. The CMOS/TTL designation just seems to be to distinguish the spec of 2.4V for TTL and Vdd - 0.4 for CMOS. Vdd - 0.4 would still give at least 2.4V out down to a supply of 2.8V but spec says its maintained to 2.7V Vdd. At 3.3V and 8mA it should be at least 2.9V.

That assumes there is no noise from the other lines in the bus or the environment.

I *love* the STM32 series.  I've spent more time with those and Mecrisp than any other MCU.  But it's the wrong tool for driving TTL devices.  They are 5 V tolerant, so it's OK to use one to listen.

Why make something that is inherently unreliable by design?    It's begging for trouble when you least expect it and it causes you the most pain.

[WaveyDipole]

Everytime I receive a new one, I perform these steps to install the firmware from stm32duino:
1. I connect a FTDI to the blue pill
2. I move the "upper" jumper to 1
3. I connect the FTDI to a USB port. I verify that it appears as "Prolific USB To Serial Port (COM 6)" (6 or whatever other port)
      If this step fails, I download PL2303_64bit_Installer that installs version 3.8.18.0 (this one works for Win10)
4. Then I go to "C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win"
5. I then execute this line: stm32flash.exe -w ..\..\STM32F1\binario\generic_boot20_pc13.bin COM6 (6 is an example, you should use the previous port)
6. I shift the upper jumper back to "0"

Then I use the arduino IDE with the following settings (in the "Tools" menu):
Board: Generic STM32103C
Variant: STM32F103CB (20k RAM, 128K Flash)
CPU Speed: 72MHz
Upload Method: STM32duino Bootloader

Sometimes when I'm uploading the sketch it gets stuck waiting for the DFU interface, if that happens I quickly reset it (so it starts in DFU mode) and that's enough to make it work.

Thanks for sharing that process.

[artag]

I rebuilt my ar488 today and when testing, noticed that ++rst caused it to enter a reboot loop.

I think what's happening is that I'm using a nano with the 'old bootloader'. Early versions of the arduino bootloader didn't deal with watchdog resets properly, and ++rst uses the watchdog timer to reset the board.

The watchdog reset status bit gets set and isn't cleared by a button-reset operation (also the reprogramming reset) so a power cycle is needed to get it working again. I haven't tried this with the later (uno-style) bootloader but I expect that to fix it. Many nanos are still supplied with the old (Duemilanove) bootloader.

[artag]

I've got this code working with the arduino pro micro, which has a built-in USB port. It's also a very small board that fits neatly on the back of a GPIB connector, making a really tiny interface.

I've designed (but not yet received) a PCB to mangle the wiring appropriately but will publish that once it's proven.

Waveydipole has a copy of my changes (which also support the Uno and Mega versions in the same Arduino project) and will make that available in due course.

Apart from the size (an arduino nano also fits quite nicely on the back of a plug), the use of the 32u4 should make it possible to support the RTS/CTS pins correctly (though I haven't tried to do that yet) and maybe at some point support USBTMC as an alternative to serial.

[bitseeker]

That sounds cool. Looking forward to seeing it.

[artag]

It seems that the CDC serial port driver used by the arduino (and most other) USB virtual serial ports doesn't support CTS from device to host. This isn't a shortcoming of the serial port, it's not present in the CDC spec and hence not available in the OS driver. So it isn't possible to trivially add it to satisfy EZGPIB. Other possibilities are emulating a device that does have hardware CTS (and using its driver on the PC, rather than the CDC driver), or emulating some other device EZGPIB supports such as an NI adapter.

A good description of the issue here : https://www.microchip.com/forums/m746114.aspx , here http://janaxelson.com/forum/index.php?topic=1414.0 and here http://janaxelson.com/usb_virtual_com_port.htm

It seems worth doing. EZGPIB has some excellent features and if you look at the code you find an incredible wealth of knowledge about the quirks of certain instruments. I've tended to avoid it since it's only offered for Windows, but after discovering how thorough it is, and that it seems to be sufficiently well-behaved to work reliably under Wine, I'm inclined to investigate it further.

Waveydipole has kindly put the pro micro / uno / mega combined version up at https://github.com/Twilight-Logic/AR488/tree/master/Contributed/artag

[maxwell3e10]

It seems that the CDC serial port driver used by the arduino (and most other) USB virtual serial ports doesn't support CTS from device to host. This isn't a shortcoming of the serial port, it's not present in the CDC spec and hence not available in the OS driver. So it isn't possible to trivially add it to satisfy EZGPIB.

There is a simple way to edit EZGPIB executable to make it ignore the CTS/RTS control. See http://www.dalton.ax/gpib/ at the bottom under "Notes".

It is in fact easy to use EZGPIB, although sometimes it behaves in somewhat funny ways.

[artag]

There is a simple way to edit EZGPIB executable to make it ignore the CTS/RTS control. See http://www.dalton.ax/gpib/ at the bottom under "Notes".

Yes, that solution appeared earlier in this thread. But patching binaries isn't an ideal solution, even when it's a 7-year-old release and the author died 5 years ago. It probably makes more sense to change the code : the source is available. or possibly not  - I may be confusing it with the KE5FX suite.

[WaveyDipole]

I have now uploaded a new version (0.47.36) that combines the Uno/Nano and Mega code into one code base. All configuration, including board selection and macros, is now done in the separate Config.h file and a new module called AR488_Hardware has been added and contains the platform specific code.

In addition there is an option to specify a custom layout. The caveat is that interrupts have to be disabled in favour of in-loop checking of the status of the SRQ and ATN (device mode) pins. It has come to my attention that some alternative boards do not support features as SerialEvent or EEPROM. I have therefore removed SerialEvent dependent code as SerialEvent has to wait for the loop anyway so there should be no performance penalty. I have provided an option to disable EEPROM support. The functional code is essentially the same otherwise.

The new code architecture should facilitate adding support for further boards as the layout can be easily added to the AR488_Hardware module. I would like to add support for the 32u4 (artag - see contributed code) and STM32 (mlefe). I have received my 32u4 boards, but it looks like I might have to wait another month for the STM32 ones! I am also considering adding another separate C++ module for external hardware such as sensors or relays etc. Bluetooth has been temporarily removed because the code needs to be updated to work with the new sketch architecture, although the previous version (0.46.32) is still available in the Archive directory should anyone need it.

At present I am currently trying to finish the ESP8266 WiFi add-on which will then allow me to move on to the ESP32.

I would like to say that I appreciate the support and interest that has been shown in this project in the last couple of months. Thank you 

[artag]

PCBs have arrived, and it looks like they work (not too surprising as it's a completely passive circuit that I'd already breadboarded).

The result is pretty pleasing : a usable (~20kbyte/s transfer) cheap (<£10) USB adapter that's smaller than the traditional IEEE-488 stacking plug.

[artag]

more pics

[artag]

Could really do with a case to stop things shorting out and some strain relief for that fragile USB socket.
Maybe a 3d print ? Or a laser-cut acrylic sandwich ?

[vindoline]

Artag, nice work! That's pretty sweet.

[metrologist]

exactly the way I envisioned it. 

[artag]

If anyone wants to copy the version I built, you can get PCBs from here : https://oshpark.com/shared_projects/HrS1HLSE

I will probably revise that at some point (I'd like to move the daughterboard further along, making the USB connector stick out less) but don't know how long I'll take to get around to that. The electrical connections will stay the same so the software will still work.

[ebclr]

Could you please point the connector specs or datasheet, or even where to buy

[artag]

I used https://www.ebay.co.uk/itm/391507935311 part '24 way plug EB67E PCB mount' but from Digikey I think it's https://www.digikey.com/product-detail/en/norcomp-inc/111-024-113L001/1024PMA-ND/955147

There seem to be several 'pro micro' arduinos around. I used the cheap common one from ebay, 5V version (there is also a 3v3 version) eg https://www.ebay.co.uk/itm/264238513729 (that link is a UK stockist - if you get it direct from China they cost a bit less).

The PCB should be assembled with the arduino on the silkscreened side. Pin 1 on the PCB is indicated by having a square pad instead of an oval one - this should be the pin marked TXD on the arduino. The connector goes on the side with no silkscreen : again, pin 1 has a square pad.

You need to assemble it in a specific order or you can't get to the pins to solder them.

1 : solder the 12-way header pin strips to the silkscreen side, short end in the pcb, long end sticking out
2 : solder the connector on the side with no silkscreen
3 : clip the surplus length of connector pin off short (so they don't touch the back of the arduino board).
4 : fit the arduino over the long ends of the header pins, with the USB connector upwards and at the 'AR488' end of the board
5 : solder the pins and clip them short

you should probably then

6 : put some hot-melt glue over the ends of the header pins where they're close to the metal connector shell (danger of shorts)
7 : cover the rest of the arduino to prevent shorts and damage
8 : strengthen the USB connector with epoxy

You could also build it with a female connector but then you'll have to assemble it as a mirror image - connector on the silkscreened side and arduino upside-down (USB connector trapped between arduino pcb and ar488 pcb)
 

[rhb]

It's finished!  :-)

I got my enclosures today and my first AR488 GPIB-USB interface is completed.  This one is for AR488 FW development and to operate a stack  of 2x 34401As.  It will later move to the 2x 3478As when I build the 44421A 20 channel switch for monitoring voltage references.

Next task is to add functionality to AR488 to read the 328P  internal temperature sensor.

Have Fun!
Reg

BTW the enclosure is 100x60x25 mm and under $1 from Hong Kong.  I bought 5 from US stock, but just ordered 20x more from HK.  It's a very convenient form factor for lots of things.