In theory, any piece of software could be built out of discrete pieces of hardware, provided there are enough transistors, passive components, and time available. In general, though, we’re much more likely to reach for a programmable computer or microcontroller for all but the simplest tasks for several reasons: cost, effort, complexity, economics, and sanity. [Igor Brichkov] was working with I2C and decided that he wanted to see just where this line between hardware and software should be by implementing this protocol itself directly with hardware.

One of the keys to “programming” a communications protocol in hardware is getting the timing right, the first part of which is initializing communications between this device and another on the bus. [Igor] is going to be building up the signal in parts and then ORing them together. The first part is a start condition, generated by one oscillator and a counter. This also creates a pause, at which point a second oscillator takes over and sends data out. The first data needed for I2C is an address, which is done with a shift register and a counter pre-set to send the correct bits out on the communications lines.

To build up the rest of the signal, including data from the rotary encoder [Igor] is using for his project, essentially sets of shift registers and counters are paired together to pass data out through the I2C communications lines in sequence. It could be thought of that the main loop of the hardware program is a counter, which steps through all the functions sequentially, sending out data from the shift registers one by one. We saw a similar project over a decade ago, but rather than automating the task of sending data on I2C it allowed the user to key in data manually instead.

While the Bus Pirate 5 is an impressive piece of hardware, the software is arguably where the project really shines. Creator [Ian Lesnet] and several members of the community are constantly working to add new features and capabilities to the hardware hacking multi-tool, to the point that if your firmware is more than a few days old there’s an excellent chance there’s a fresher build available for you to try out.

One of the biggest additions from the last week or so of development has been the I2C sniffer — a valuable tool for troubleshooting or reverse engineering devices using the popular communications protocol. [Ian] has posted a brief demo video of it in action.

It’s actually a capability that was available in the “classic” versions of the Bus Pirate, but rather than porting the feature over from the old firmware, [Ian] decided to fold the MIT licensed pico_i2c_sniffer from [Juan Schiavoni] into the new codebase. Thanks to the RP2040’s PIO, the sniffer works at up to 500 kHz, significantly outperforming its predecessor.

Admittedly, I2C sniffing isn’t anything you couldn’t do with a cheap logic analyzer. But that means dealing with captures and making sure the protocol decoder is setup properly, among other bits of software tedium. In comparison, once you start the sniffer program on the Bus Pirate 5, I2C data will be dumped out to the terminal in real-time for as long as you care to see it. For reverse engineering, it’s also very easy to move quickly from sniffing I2C packets to replaying or modifying them within the Bus Pirate’s interface.

If you already have a Bus Pirate 5, all you need to do is flash the latest firmware from the automated build system, and get sniffing. On the fence about picking one up? Perhaps our hands-on review will help change your mind.

It is easy to forget that many technology juggernauts weren’t always the only game in town. Ethernet seems ubiquitous today, but it had to fight past several competing standards. VHS and Blu-ray beat out their respective competitors. But what about USB? Sure, it was off to a rocky start in the beginning, but what was the real competition at that time? SCSI? Firewire? While those had plusses and minuses, neither were really in a position to fill the gap that USB would inhabit. But [Ernie Smith] remembers ACCESS.bus (or, sometimes, A.b) — what you might be using today if USB hadn’t taken over the world.

Back in the mid-1980s, there were several competing serial bus systems including Apple Desktop Bus and some other brand-specific things from companies like Commodore (the IEC bus) and Atari (SIO). The problem is that all of these things belong to one company. If you wanted to make, say, keyboards, this was terrible. Your Apple keyboard didn’t fit your Atari or your IBM computer. But there was a very robust serial protocol already in use — one you’ve probably used yourself. IIC or I2C (depending on who you ask).

I2C is robust, simple, and cheap to implement with reasonable licensing from Philips. It just needed a little tweaking to make it suitable for peripheral use, and that was the idea behind ACCESS.bus. [Ernie] tracked down a 1991 article that covered the technology and explained a good bit of the how and why. You can also find a comparison of A.b, I2C, and SMBus in this old datasheet. You can even find the 3.0 version of the spec online. While DEC was instrumental in the standard, some of their equipment used SERIAL.bus, which was identical except for using 12 V power and having a slightly different pinout.

The DEC Station 5000 was an early adopter of ACCESS.bus. From the user’s guide:

In theory, one ACCESS.bus port could handle 125 devices. It didn’t have a hub architecture like USB, but instead, you plugged one device into another. So your mouse plugs into your keyboard, which plugs into your printer, and finally connects to your PC.

The speed wasn’t that great — about 100 kilobits per second. So if ACCESS.bus had won, it would have needed to speed up when flash drives and the like became popular. However, ACCESS.bus does sort of live even today. Computer monitors that support DDC — that is, all of them in modern times — use a form of ACCESS.bus so the screen you are reading this on is using it right now so the monitor and PC can communicate things like refresh rates.

We love to read (and write) these deep dives into obscure tech. The Avatar Shark comes to mind. Or drives that used photographic film.