TLDR: A small exploration of the use case of hardware over software.
"Bit-banging" ...what?
Apparently, bit-banging is when you are trying to do with software what should be done with hardware. What an entertaining thought. Has anyone done this? I would love to hear your story.
This is that area in computer science where software developers probably start to stick up their nose. Circuit? Excuse me? 😆 Leave that to the hardware engineers.
Guys, we have to play nice and communicate here. Did you know that when it comes to development, some argue there is up to 7,000 communication protocols globally? In all fairness, most of us only use a handful. But still, if you can handle the vast majority of communication protocols for web development, surly you can handle the small amount that exist in hardware. The focus is on one today: SPI.
SPI - Serial Peripheral Interface
A four-wire, high-speed, full-duplex protocol for synchronous communication between microcontrollers and peripherals.
In one of my classes, we had to come up with a project where we implemented a PLD into a circuit. I looked into use cases for such a thing, and discovered a CPLD is very useful in cases where timing is absolutely critical, or else the system would dysfunction.
I happen to be a big fan of programmable LEDs.
It is entirely possible to wire an ESP32 directly to an LED strip, but there are a lot of problems with connecting directly, and I have witnessed them in person. Challenges with the ESP32 include:
- It runs a multitasking operating system, and interruptions from wifi can disrupt timing precision.
- If the timing is off, the LEDs will display the wrong colors or glitch.
- Inconsistent timing resulting from this could lead to the wrong colors displayed.
- Disabling interrupts would also drop wifi packets, leading to intermittent connectivity and exacerbating the problem.
And returning to the concept of bit-banging...
This is probably one of those topics that software engineers should pay closer attention to. Some things are best left to hardware. The bit-banging software approach to handling the circuit introduces more inconsistent timing due to wifi, timer, and serial port interrupts. The timing must be nearly perfect for it to work as expected. Bit-banging can lead to high CPU usage for moderate reliability.
THE SOLUTION
So what can be done to run our multitasking OS alongside a fluid light show? We can fool the audience by offloading the timing-critical LED driving to hardware. The ESP32 talks to a CPLD (complex programmable logic device) through a serial peripheral interface. In this arrangement we have a wire for data, clock, select, and ground. I was very excited to learn about how these connections all work, so I made a diagram that represents the physical connections between each set of circuits.
This gives a high level understanding of our circuit structure. The CPLD takes the serial data from the ESP32 controller and uses memory to store the information. A pulse generator will also be built as part of the CPLD to make sure that we do not have timing issues. A unique feature of the SPI protocol is that it allows data to be transferred without interruption. This is the really important part. Instead of doing an internal eye roll over performance issues, I would encourage you to try it out. With these boards you don't even need to solder. You just connect the pins, like adult legos. Easy-peasey.
Now, the speed of data transfer is determined by the frequency of the clock signal. This means that we can make the lights change faster or slower by controlling the frequency of the clock. Cool. A faster clock speed means LEDs will update more frequently, and a slower clock speed will make them update in a slower manner.
Let's Talk Real Life
In real hardware, code is written to describe both parts of the CPLD. The synthesis tool converts it to actual logic gates and flip flops. The CPLD contains both the SPI receiver and the pulse generator (which controls the timing).
A nice board that could be used in a project like this could be the Altera MAX II EPM240 CPLD Development Learning Board that I found online. In the picture below, we see the top row of input pins with the GND and +5V on the very right. The programmable logic of the CPLD happens inside of the central black square. On the bottom, a row of output pins is aligned.
Might have to try this out and see what happens. Am I stepping into the unseen madness that is hardware? It is uncertain, but very curious indeed Mr. Watson.