Looking for developer guide - minimal GPIB firmware implementation (bare-metal)

[wb0gaz]

I've prepared on a small PCB a STM32C0 microcontroller, a PCA9555 GPIO expander (via I2C) and a Norcomp male connector (as is used to plug into a GPIB-enabled device.) This would make the attached GPIB machine accessible via I2C commands to the PCA9555, which is my current starting point.

At this point, I'd like get started writing my own GPIB code (C language) for use as a controller (i.e., plugs into some other instrument that will be controlled) WITHOUT relying on any existing library, source code, or other tools (beyond the STM32 IDE.) This is definitely "reinvent the wheel" but I'm doing this for entertainment (yes ?!?!), not publication, employment or other coercision.

I'm looking for a basic GPIB timing diagram or other that would guide me to the point where I can verify that my homebrew GPIB code is indeed communicating with an external device (for example, a HP 8970-series noise figure analyzer or HP 8753-series vector network analzyer.) I expect I'll be writing rudimentary PCA9555 instructions (via I2C) to configure each (of the 16 attached bus lines) as input, output-low, output-float, output-high, etc.) and interacting solely with those primitives to reach the point where the GPIB-enabled attached instrument shows signs of recognizing a tranasction targeting its GPIB bus address.

This will be a bare-metal exercise (my personal pile of C code already handles the PCA9555 to my liking and the PCA9555 facing the GPIB connector is responding as expected), so I'm focused on getting to the minimal milestone of causing the attached instrument to acknowledge the beginning of a transaction so I can focus more on software, less on hardware validation/troubleshooting.

Thanks for any suggestions (except for harnessing existing library/code/project, as I'd like to do this task from ground up.)

Dave

[Renate]

Why would you go through I²C?
That's a bottleneck for speed and a hassle for programming.
Just use a board with 16 I/O, at least 8 contiguous bits for data just to make your life easier.
Even a ATMega32u4 has adequate processing power for this.

[wb0gaz]

Thank you, Renate - you successfully found missing information in my posting!

You are correct I2C will be bottleneck (at least!), and means very limited or non-existent support for flexible interrupt handling. For this, I agree your comment.

My use of I2C is only for convenience and host CPU is 8-SOIC package.

This exercise is only at this time to provide me some experience writing GPIB protocol from scratch. Therefore, details of physical pathway are not important. Of course given working GPIB code, I can adapt physical layer as needed. So, this project is leveraging hardware I already have.

Thank you again for your information!

Dave

[westfw]

There have been a couple of major HPIB projects discussed here that might prove useful to look at...

https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg6270134/#msg6270134
https://www.eevblog.com/forum/projects/poe-ethernet-gpib-adapter-open-source-project-now-public/msg5762141/#msg5762141

(I don't think either one is either "minimal" or "bare metal", but ...)

[wb0gaz]

Thanks, Westfw - those will be helpful (I haven't surveyed either project, so that's clearly a piece of homework I need to do before setting out...)

Much appreciated!

Dave

[cfbsoftware]

I'm looking for a basic GPIB timing diagram or other that would guide me to the point where I can verify that my homebrew GPIB code is indeed communicating with an external device

Try searching for IEEE488 rather than GPIB. The many results this came up with included the specs for the Tektronix P7001/IEEE 488 Interface:

https://w140.com/tekwiki/images/7/7f/070-2623-00.pdf

[edpalmer42]

Another useful acronym to search for is SCPI (Standard Commands for Programmable Instrumentation) which is an expanded version of IEEE-488.2.

Depending on where you live, you might be able to go to your public library and request an inter-library loan to get access to documents that would normally be behind a paywall, e.g. the actual IEEE-488.2 specification.  This may be free or at a nominal cost.  YMMV.

FYI, in the beginning there was HPIB (Hewlett Packard Interface Bus) which begat GPIB (General Purpose Interface Bus) which begat IEEE-488 / 488.1 / 488.2 which begat SCPI.  Older equipment can be a real PITA to get working with modern software implementations so some flexibility in that software - maybe even going above (below?) the specification will be useful.

[pqass]

This guide may be helpful.
Or, get what you need from the (two volume) source.

[az1]

Another useful acronym to search for is SCPI (Standard Commands for Programmable Instrumentation) which is an expanded version of IEEE-488.2.

Depending on where you live, you might be able to go to your public library and request an inter-library loan to get access to documents that would normally be behind a paywall, e.g. the actual IEEE-488.2 specification.  This may be free or at a nominal cost.  YMMV.

FYI, in the beginning there was HPIB (Hewlett Packard Interface Bus) which begat GPIB (General Purpose Interface Bus) which begat IEEE-488 / 488.1 / 488.2 which begat SCPI.  Older equipment can be a real PITA to get working with modern software implementations so some flexibility in that software - maybe even going above (below?) the specification will be useful.

Took a bit of googling but I was able to find PDFs of 488.1 and 488.2 (as well as some guides from HP that postdate 488.2) freely available online.

[wb0gaz]

Thanks (was offline couple of days since last update) - appreciate the additional resources, got plenty of reading material now.

As for SCPI, my current focus is on a much lower level of the protocol stack - this is a "bare metal" type activity, and I'm currently focusing on what sequence of states/transitions in the hardware bus are required (with my device acting as controller) to elicit any sort of response from the addressed device; this is definitely a "re-invent the wheel" activity (intentional, in this case!)

Thanks again for the assistance!

[free_electron]

get the official ieee488 standard document from hp/agilent/keysight. that tells you everything you need.

it's just a transport bus. what you send of it is a different layer.

but. PLEASE use the correct bus drivers ! don't wire up directly to the bus. it may work for 1 instrument but the moment you have a 5 or 6 you will not meet signal criteria.

[wb0gaz]

Hello free_electron - currently I'm focusing on bringing up very basic firmware (just enogh to interact with one instrument as a device, my firmware/project as the controller), so there would be a most one client device connected locally (no cable, just the PCA9555 directly attached to the test device). I do have the 75160/161 devices which would go into a later version of the hardware once I'm able to establsh basic contact with one device.

Thanks for the suggestion!

[free_electron]

focus on getting the datastream working. don't try to create intelligence in the controller. The host assembles a packet and the controller sends that with appropriate handshaking to the target. that's all you need to do. after all, it's all ASCII text (mainly... unless you do binary transfers for sending images from scopes, but that is another can of worms)

[wb0gaz]

I understand and that makes good sense, however, this project is specifically for "entertainment" - I want to start by implementing the nuts-and-bolts of GPIB control at the bit/wire level, so I'm starting from "there are 16 active-low logic signals and 8 grounds, then......."

[bateau020]

There have been a couple of major HPIB projects discussed here that might prove useful to look at...

https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg6270134/#msg6270134
https://www.eevblog.com/forum/projects/poe-ethernet-gpib-adapter-open-source-project-now-public/msg5762141/#msg5762141

(I don't think either one is either "minimal" or "bare metal", but ...)

The last one uses the GPIB HW layer from the first.

Another approach is from xyphro https://github.com/xyphro/UsbGpib

Recommendations (partially already mentioned above):
* get a logic analyzer (16 channels)
* work with true 5V, if needed use the 75160/75161/75162 chips
* try it on some really old (HPIB era) gear, as it is the same bus, but not exactly the same behaviour.

[wb0gaz]

Thank you, your suggestions are all helpful, much appreciated!

Time to dig out the old Digilent (yes, having logic analyzer will be helpful)!

Dave

[Renate]

Time to dig out the old Digilent (yes, having logic analyzer will be helpful)!

A $5 FX2LP PCB logic analyzer has to be the peak value in utility per dollar of any test equipment.

[wb0gaz]

Renate - thank you very much! I was not aware of that device - ordered!

[m k]

GPIB system concepts page 6/12.

[wb0gaz]

Thanks m k - quick look through that document it appears to walk me through forming a message and the associated control lines - I hadn't thought of looking for write-ups like this embedded in test equipment manual - helpful!

Dave

[rf-fil]

Is this techno-paleontology project mostly for education / interest? Otherwise, why not just get a GPIB dongle?

[wb0gaz]

Hi VK2ZJ - this effort is *exactly* for fun/entertainment (something I included in my first or a very early posting in this thread, however, the thread has become somewhat longer than I expected, so I understand that the for-fun aspect is probably not quickly picked up. Anyway, definitely any commercial/open source adapter would be the fast way to use GPIB, but "bit twiddling" is something I enjoy (I'm exploring the STM32C0 low-end microcontrollers and the GPIB effort is one of several for-fun firmware projects.) I don't plan to publish or necessarily finish the GPIB work; a success would be getting my ancient HP 8753A VNA to do "something" at the behest of bare-metal code I write myself.

[wb0gaz]

Hello Renate,

I now have two of those FX2LP boards; I'm going to lay out a PCB with a pair of GPIB connectors (male/female) and receptacles to let me install the two boards onto this new board. I'll attach 8 data lines to one of the FX2LP and 8 control/command lines to the other FX2LP. As I've not used this module previously, do you have any suggestion on recommended software application to use the FX2LP as a logic analyzer?

Thanks again for your suggestions and inputs on this project!

Dave

[Renate]

As I've not used this module previously, do you have any suggestion on recommended software application to use the FX2LP as a logic analyzer?

As a logic analyzer, just use a single FX2LP, there's enough pins.
For software use PulseView from sigrok: https://sigrok.org/wiki/Downloads
There is already a built-in GPIB software decoder in that.

An FX2LP is by itself not a very good choice for a GPIB controller or device.
It's a 3.3V device so the outputs are marginal (the inputs are 5V tolerant and just fine).
Moreover, the FX2LP is an 8051 (archaic) processor, which is just fine if you're using canned software but I wouldn't want to write for it.
Also, it needs the firmware uploaded into it, operationally a nuisance.
All of this is fine if you use it with PulseView and ignore the ugly underbelly.

[bateau020]

yes, you will want the 16 lines on the same logic analyzer, makes the decoding much easier.