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

[Doctorandus_P]

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.

[rcjoy]

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

[Darkover]

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

[wb0gaz]

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

[wb0gaz]

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

[bateau020]

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

[wb0gaz]

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

[wb0gaz]

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

[artag]

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.

[wb0gaz]

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

[artag]

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.

[wb0gaz]

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