Since filming this, I've moved to hardware spi and added two more buttons to allow adjusting brightness (mode and brightness settings are saved to nonvolatile eeprom).

So I'll be honest the beginnings of this project were very much inspired by this recent HAD project post https://hackaday.com/2021/07/14/analog-style-vu-meter-with-arduino-and-oled-display/

This is why I love HAD, coming up with creative original ideas is very difficult with the saturated diy maker world but seeing what other people are doing is a great source of inspiration to starting similar projects with improvements sparked by the lessons learned by past projects others have done!

So while what I've implemented is certainly not unique, it's interesting to me nonetheless. From the original project I referenced above I saw two main issues I'd like to resolve. The first is each display required it's own arduino to drive it, one for the left channel and one for the right one. I've implemented my own bitbanged spi oled driver code in the past, so it was simple to update it to support two displays each with their own chip select pin, but sharing the rest of the control pins. This meant one chip could drive two displays, sequentially. My bitbang spi code uses direct port manipulation, and can refresh one screen at just above 40Hz (so logically dividing the communication bandwidth between 2 displays will mean each display can updated at around 20Hz max each). It'd be trivial to change the code to support hardware spi which would greatly further increase speed, but I don't think that's necessary at the moment.

The second issue I seek to improve is that the meter movement in the original project looked a little too perfect and instantaneous, as you'd expect with a digital display. If you've ever seen a mechanical meter movement it's apparent that the mass of the needle and the spring that is attached to it to return it to zero when no signal is driving it add a physical response to impulses. The needle will take a little while to accelerate/decelerate, often overshoot the setpoint a little, and slightly oscillate around the point till it reaches equilibrium. This is the exact behavior I want to approximate with my virtual needle on a digital oled display.

To accomplish this I've implemented a PI controller (basically a PID controller without the differential term). Conventionally such a controller is used to smooth out physical responses so an output can reach a setpoint as quickly as possible without ringing or overshoot, but I'm ironically adding it to add those desirable features for this application lol, by purposely selecting gains which result in underdamping. Here's a snippet of code to demonstrate generally how the PI controller is implemented:

As you can see, if the setpoint is much larger than the current needle position the error will be large and the correction applied to the next position will be large as well. And if the error has been non-zero for quite awhile, the accumulated error term will be large, further increasing the corrective action. Notice also that these terms can be positive or negative in order to force the corrective action in either direction to keep acting until the needle position and setpoint are the same (thus...