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.
If you think this is wild, have a look at how a Model 15 teletype decodes the incoming serial bitstream in real hardware. That is: Without a single semiconductor.
The fire was incorrectly put out.
That hardware was designed without CAD and built without CNC machines too.
Ya so … electronics
Even when I was a teenager 25 something years ago getting your hands on a basic programmer for a micro cost a few car payments… and yet radio shack sold chips for less than a buck at your local mall… this was how it was done
That’s true.
On the other hand, about 35 years ago, getting your hands on an EPROM programmer was dirt cheap!
Why? Because home computer users could direct wire EPROMs to their 8-Bit machines. By using user port, module port etc.
The cheapest EPROM programmer was an C64 with a little EPROM programmer module module.
In the 90s, EPROM programmers for PC had rocket sky high in terms of price by contrast.
The whole Galep or Willem series comes to mind.
Did cost as much as a car and had needed a parallel port.
That’s why PIC16C84 and had been such a success in the 90s and early 2000s also (16F84, 16F84A).
The PIC could be programmed serially, either via serial or parallel port.
There had been a lot of circuits.
Those using a battery instead of sucking power from data lines were more reliable, I think.
There also were Basic stamps, picaxe etc.
But they were still a bit too pricey for a pupil or student.
They were alternatives, though, at least.
That said, if you have EPROM at hand, there is a smarter way to do this sort of sequential bit streaming.
Suppose you have 8 data lines. You loop 7 lines back to address select and use the remaining one as your output signal. Each memory location contains the address for the next data bit, which contains the address for the next, and so-on. You can even do conditional loops by using some parts of your address space for different sequences.
No CPU, only memory. In principle you can do the same without the EPROM using a diode matrix and some extra logic, but that’s going to be more work than it’s worth.
Grok3 can show you how to build a compiler in C that successfully translates a Brain𝑓μck subset into EEPROM values.
There was an EPROM programmer for the C64 35 years ago? I didn’t know one existed back then. That was the whole basis for my Senior design project – creating a programmer for the C64 because of the exorbitant prices for an EPROM programmer for an IBM compatible computer. My MCU of choice was the Motorola 68705 series. Loved those controllers, then the FLASH-based ‘908, etc. They way the MCUs were programmed was to use a pre-programmed EPROM, then stick it into a programmer circuit with the desired MCU to program, flip a few switches, and then a ROM routine within the MCU would program itself with the preprogrammed EPROM. What my project did was use the User port to load up a RAM module with the bitstream. Then once it was loaded, the user would flip a few switches just like before and the MCU would use the RAM to program itself. I even wrote an assembler to create the bitstream. It worked. I was so happy. Don’t know if complex programs would have assembled correctly as I only created a basic program to demo to my professor. :-) I still have the big bread-boarded circuit right here in my work room.
A microprogrammed state machine is the next step up. The drawback is the high clock speed required, but the payoff is increased flexibility over a straight combinational FSM design.
Part 2 of this showing complete working schematic
https://youtu.be/KoXC1Ikywj4?si=yWKR9ns-PwnwvgQq
Counts as finger banging.