EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: wb0gaz on June 06, 2026, 03:33:20 pm
-
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
-
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.
-
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
-
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/ar488-arduino-based-gpib-adapter/msg6270134/#msg6270134)
https://www.eevblog.com/forum/projects/poe-ethernet-gpib-adapter-open-source-project-now-public/msg5762141/#msg5762141 (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 ...)
-
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
-
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
-
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.
-
This guide (http://www.bitsavers.org/pdf/hp/hpib/TutorialDescrOfHPIB.pdf) may be helpful.
Or, get what you need from the (two volume) source (https://duckduckgo.com/?q=IEEE-488+pdf+site%3Awww.hhcworld.com).
-
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.
-
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!
-
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.
-
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!
-
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)
-
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......."
-
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/ar488-arduino-based-gpib-adapter/msg6270134/#msg6270134)
https://www.eevblog.com/forum/projects/poe-ethernet-gpib-adapter-open-source-project-now-public/msg5762141/#msg5762141 (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 (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.
-
Thank you, your suggestions are all helpful, much appreciated!
Time to dig out the old Digilent (yes, having logic analyzer will be helpful)!
Dave
-
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.
-
Renate - thank you very much! I was not aware of that device - ordered!
-
GPIB system concepts page 6/12.
-
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
-
Is this techno-paleontology project mostly for education / interest? Otherwise, why not just get a GPIB dongle?
-
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.
-
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
-
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 (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.
-
yes, you will want the 16 lines on the same logic analyzer, makes the decoding much easier.
-
My use of I2C is only for convenience and host CPU is 8-SOIC package.
What sort of convenience is it if you have to add another chip just because you choose a SOIC-8?
My own idea of convenience is to use a 40 pin development board even if I just need a few pins. This way I can just use the same uC for (nearly) all my projects. And more importantly: I can use a bunch of extra pins for debug output. Catch the data with either a Logic Analyzer or a terminal program (or both).
I've read so many posts of people using an 8 pin device (for no particular reason) and then getting into trouble because they don't have enough pins.
-
I've found that this early HP document from 1975 gives a good description of the low level details.
"Condensed Description of the Hewlett-Packard Interface Bus"
https://archive.org/details/bitsavers_hphpib5940riptionoftheHewlettPackardInterfaceBusMa_1046026 (https://archive.org/details/bitsavers_hphpib5940riptionoftheHewlettPackardInterfaceBusMa_1046026)
-
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.
I don't think there is a manual, at least there was no when I did the same 25Year ago. (AT-Mega8, PCF8574, USBN9603) But there was a CircuitCellar projekt 30years in the past. I read this and learn anything that was necessary to be a bus controller and read a screenshot from my scope. Of course I2C made this aproach a little bit slow, but it is enought for most cases. Don't forget the GPIB is working with opendrain 5V and not 3.3V that we use in this days. ;)
Olaf
-
Renate, Bateau - thank you - I will using single analyzer and follow expected wiring for using GPIB software decoder - that will make it much easier!
Doctorandus_P - of course 8SOIC + port expander is not efficient compared to normal size CPU, however, in this case I am repurposing another personal hardware project (add GPIB connector I already have to hardware design I already have), and purpose of this project is to have personal experience implementing the firmware for low-level GPIB operation, so the added step of driving GPIO pins via I2C expander is only small "layer". In any event, I agree with your basic observation!
rcjoy - thank you for the reference, I have now added it to my personal GPIB library of old documents! I had not seen that one before, much appreciated!
Darkover - I do not plan try write any firmare for the analyzer CPU - I am experienced developer using Intel 8748 in assigned projects during late 1970s (my first experience with assembly language was 1969-1970 with DEC PDP-8 - almost 60 years ago!) The 8748 was improvement in some way from Intel 8008 (8008 required many support ICs to access memory, I/O, etc.)
Thank you (all) again for the kind and helpful guidance on my learning adventure!
Dave
-
Update on experiment started 6/6/2026 ---
A PCB was created with two parts, each with male and female GPIB 24 pin connector. One half has 16 LEDs (lit when signal grounded/active) and 16 pushbuttons (manually pull signal to ground); other has one of those FX2LP modules situated between the two connectors.
As it turns out, the boards above haven't added much value so far; a small addition to my program to let me set individual lines active and look at all 16 lines was sufficient to set target address on the 8-bit data bus and assert individual control lines (so far, IFC, ATN, REN and DAV) as needed.
I've tried three target devices; a NARDA 7000A microwave multimeter didn't respond at all; a HP 2225A thinkjet printer (no cartridge or paper) did respond to it's address when addressed as a listener (that did verify that I got the pin/port assignments correct), and a HP 436A/22 RF power meter responds to it's address as a listener and lights the REMOTE LED as expected. Haven't yet tried controlling the 436A nor using it as a talker, that's next.
The FX2LP data analyzer module, running Pulseview 0.4.2, didn't turn out to be useful, as the software lacks any sort of software-only trigger function (any trigger requires a capable analyzer module, the FX2LP lacks any such hardware capability, the software has no mechanism to create a rudimentary software-only trigger, and the software can't be set to continuously update the (16) traces. As both of those are existing feature requests, perhaps a developer will take a crack at either/both.
Thanks again for the suggestions and comments over the last few weeks - I think the "bit twiddling" experiments with IEEE-488 bus will yield the intended leanings and entertainment value...
-
The timing requirements are critical. The 200ns response to ATN is very tough to do with any sort of multiplexing. To do it properly, you will either need multiple threads, or some interrupt handlers. See table 39 in the ANSI/IEEE Std 488.1-1987 documentation.
About the tools: you don't need a logic analyzer for everything, a (digital) scope on the control lines (ATN being the most important) might do for limited testing.
Don't know the FX2LP, I use a dslogic plus with dsview, and it is OK. Aliexpress has them and loads of others in the same price ranges. No need for trigger, just capture for X seconds and then zoom in.
By the way, I just started (and I mean JUST started, it is unusable and untested right now) a device side GPIB library allowing me to better test the different GPIB controllers that I'm working on. See https://github.com/hb020/ieee488_device (https://github.com/hb020/ieee488_device)
-
Hello bateau020 - I was concerned about ATN response timing requirement, however my experiment is only as controller, not as device, so it appears that constraint would not apply (in my case, as i2c is driving PCA9555 GPIO expander which is providing all 16 lines, the tight timing cannot be accommodated at all, however, this is only personal experiment, so if problem arises, it would only be local impact.)
I appreciate your reference to your github project, I will follow it!
Thank you again,
Dave
-
Update from initial posting 6 Jun 2026 - the experiment software is now able to send commands to HP 436A power meter (ca. 1975) and receive responses. Although further experiments will be conducted (mostly testing vs. some other 1970s-1980s test eqiupment on hand), the project to this point has met it's objective of building from scratch a GPIB (controller role) interface with "bare metal" firmware.
Thank you (all) for the support, the ideas and suggestions were very helpful!
Dave
-
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
This might save you some effort : https://oshpark.com/shared_projects/1FVMoqoQ
OSHPark isn't the cheapest source for PCBs (though they do include postage and are good for very small PCBs) but you can download the gerbers and get it made at your favourite pcb house.
-
Hello Artag,
Thank you for the reference!
I ended up making up an almost (functionally) identical board in 50x100mm and a counterpart board (also in 50x100mm) joining the two connectors via a set of 16 LEDs and 16 pushbutton switches (the boards can be used together or separately; each board also lets me disconnect any of the 16 GPIB lines from either side of the analyzer/switch-led section.)
Re-inventing the wheel, one wooden spoke at a time!!!!
Thanks again!
Dave
-
Sorry, I'm a bit late :). That sounds useful. I was aiming at just connecting sigrok easily
If you want to do it the oldfashioned way you could look for an HP 59401A bus protocol analyser which allows for overriding signals and stepping through bus operations. Curiouis Marc uses one in a video about debugging tape drives.
https://www.youtube.com/watch?v=5J8IbpJoeqk (https://www.youtube.com/watch?v=5J8IbpJoeqk)
-
Much appreciate the video link on the HP analyzer!
I ended up given one of these analyzers last year, and finally got an original service/ops manual for it a month or so ago, but so far I've been loathe to power it up as there are probably damage risks of powering such an old device up after a multi-year slumber.
As it turns out, I was able to get the basic 3-wire interface (DAV, NDAC, NRFD) sequence going enough (without using any sort of analyzer, just re-re-re-re-re-reading the protocol descriptions thanks to prior contributions to this discussion) to get the ca. 1975 HP 436A power meter to talk and listen.
I suspect my work so far wouldn't handle the device role (I'm only using it as a master right now) as it takes some time to update the DAV/NRFD/NDAC lines and from what I've learned in my on-line wanderings, the device role imposes some response time limitations that my current design couldn't accommodate (i.e., communicating on 2-wire I2C to a PCA9555 GPIO expander, so there is all kinds of polling and transaction latency that would cause problems.)
Thanks again!
Dave