So after the failure that was prototype 1, I've decided to dispense with trying to be clever and save pins/silicon and just throw an independently controllable h-bridge chip at each of the 14 segments (2 digits per module). After all the L9110S chips I got from ebay were only about $8 with free shipping for 50 chips which ends up to comfortably make three modules with a few chips to spare. The only casualty was the nice pretty routing of the board that I was so proud of in v1.0 is now an absolute mess to squeeze the 14 soic chips in along with a larger micro for the necessary extra I/O.

So this brings me the the second notable upgrade. I was using the diminutive narrow smd PIC16F886 package in v1.0, but for 2.0 I had to upgrade to the PIC16F887. Luckily, basic code-wise nothing really changed as they both have the same core, just the 887 has a ton more I/O. The rest of the lower level code to handle all the extra outputs though had to contend with independently driving each segment, but luckily I decided to wire things such that segments were in logical order so a simple port write can easily correctly set an entire digit in one fell swoop (with a small exception of hardware rx/tx pins which required one of the segment G pins to be tacked onto another port). In terms of the communication/interrupt/higher level architecture nothing else really had to change.

I was pretty nervous firing v2.0 up for the first time when I tried to flash the firmware and my pickit couldn't even see the PIC. Oh crap, I figured I screwed up royally again, but a quick look at the schematic revealed I allocated one of the programming pins double duty with driving an h-bridge and since I only supplied 5V and not the 12V coil drive rail I suspected the pin was being logged down. Powering the 12V rail additionally resulted in my programmer being able to see and program the chip. A small setback having to supply both 5V and 12V to program but I can live with that. So I flash the processor, hold the on board button during power-up to exercise the self-test functionality that flips all segments sequentially and low and behold she's AAAAAALLLLIIIIVVVEEE!!!

The next step was to check the communication functionality and luckily everything seems to be functional with two small caveats. The first I've found is that for some reason devices with address 1 don't seem to respond to commands. Every other address 0-6 work perfectly. I'll have to dig through the code and enable debug print statements through the tx pin to figure out why. But for the meanwhile this can be avoided just by not using address 1. Programming the address is currently only possible through using an icsp programmer to flasht the eeprom (I'll likely add the ability to change the address through serial in the near future).

The second bug is more interesting. I've found that sending two packets to the same address to write to say both digits results in the module locking up and not responding to any more commands. A cheap work around is to just delay sending commands by a second to allow any process to finish. However, this is a bandaid and not a fix. I have a sneaking suspicion I am having a stack overflow. See, I handle receiving and decoding serial commands in an interrupt that calls the display write function to actually twiddle the segments. I stupidly didn't disable interrupts while executing a command. The problem is twiddling the segments takes time and if another valid command arrives before the last command is finished then the interrupt will interrupt the last interrupt which isn't quite done and the processor goes deeper down the stack rabbit hole. The PIC only have a stack depth of 9 so if it happens to exceed this (which is probably easy with all the functionception my code does) the stack will overflow and the program counter return address will point to god knows what. I have a feeling when my processor locks up it is executing some random address in no man's land in the memory space. So an easy fix that I will test is to just disable interrupts while executing a command, and let the serial fifo buffer do its job to save new commands while it is still executing an old one. Look ... I never said I was a good programmer, but this is a good learning experience.

Anyway I've mostly got things working so next is to program an esp8266 to grab my youtube sub count and send master commands to these three modules to display this info. Look forward to that in the next update!