I got a new toy in the mail today, a brand new Bus Pirate V4 (The red PCB to the left). What this wonderful piece of kit allows me to do is communicate with various IC’s using any of the standard serial interfaces (UART, SPI, I2C, etc) via USB with an easy to use serial interface. Ever since I started getting into electronics and the world of IC’s I’ve yearned for such a tool. I’ve even gone as far as to write up a set of generic MCU programs for each interface for quickly testing chips, but these could only go so far. Needless to say I bought one of these up and all I have to say after one day of ownership is that I wish I bought it sooner.
Setup was a breeze once I found the necessary .inf file for the driver. Once I was up and running I updated it to the latest and greatest Bus Pirate firmware. Something to note about this is that it’s important to short the PGC and PGD pins prior to plugging it in for an update or else it won’t set the device up for an update. Another thing is I need to buy some 90 degree 100mil headers for the programming header. Next up, I ran the self test where I discovered the need to note differences between V3 and V4 boards. Pretty much all the documentation written online is for the V3 board which has differences in drivers, pinouts, and the like. Hopefully, this will change as V4 becomes more stable and popular which I don’t think is too far down the line considering how useful this device is.
Bus Pirate in hand, I decided to go back to my reverse engineering project to see how this device can help move along the development process. From part 1 of this project I discovered that these chips were shift registers that used SPI to receive data. What I wasn’t entirely sure about was exactly how it all worked together which is what I set out to do today. First off, I hardwired the enable line to ground so the output can always be seen. Then I wired up a button for latch so I can manually strobe the data, I’m sure the Bus Pirate has a tool for this but it’s unnecessary right now. For clock and MOSI, I set the Bus Pirate mode to SPI and it immediately allowed me to set all the important parameters such as clock phase, polarity, frequency, and the like. This is incredibly useful compared to reprogramming a MCU each time you get it wrong. As it so happens, I misinterpreted the timing diagram and got the clock phase wrong but this was fixed with a few commands. Another thing to note is that the Bus Pirate always turns off the voltage regulators when changing modes as a safety feature.
I then started playing around with the small chip and learned that a logic high sent to this chip corresponds to a logic low on the pin, meaning it’s designed to control the cathode of the LED which is how it was wired. Daisy chaining a second current driver was as easy as connecting the serial out to the next serial in and sending two bytes of data. The first byte sent of course is what appears on the last device in sequence. Playing around with the big chip I realized the opposite was true, a logic high corresponded to a logic high on the pin. This led me to answer to the question in my previous post regarding the difference between the two chips. The big chip’s intent is to drive the common anodes and therefore source lots of current. These chips can also daisy chain with the small chips no problem which makes me wonder why the designers chose to have a 12 SPI bus interface. I do have to explore what the difference (if any) is between serial out 1 and 2.
The big chip also had the additional functionality of using a separate voltage source to power the LED’s, but the board’s designer’s chose not to use this. More about power, after reading further into the datasheet I noticed that the small chips had a recommended voltage of 3.3V whereas the big chips were intended for 5.0V. Probing of the board led me to the conclusion that they powered everything from one voltage source. Since the absolute maximum rating for the small chip was up to 7V I assumed they just went with the 5V power so that’s what I tried when daisy chaining the two chips together which worked fine.
At some point I tried wiring up the display which ended in disaster. My intent was to get a single row of matrices working. I first did a little rework by chaining the column chips to the single row chip so I could control the thing with one bus. Then I copied the wiring over to the control header and powered it using an adjustable DC wall wart (6V) I have that I stepped down to 5V using an LM7805 linear regulator. It didn’t work as expected, the entire row of matrices would go red every once in awhile and die. Strobing it would do something, but the results are unpredictable. In hindsight I did a number of things wrong, first off the linear regulator overheated quickly I needed to get a TO-220 heatsink for it. Next, I realized I didn’t even need the regulator to begin with. The chips and the display operate fine on 4.5V which my adjustable wall wart provides. Finally, and most importantly, I was no longer powering the chips with the bus pirate. This meant that I wasn’t sharing a common ground between the SPI master and slave, only after I disassembled it all did I realize that.
To top off the day, I made the scale single matrix prototype on the breadboard above to see where I went wrong (it was the ground ughh). It works perfectly with the big/small chip daisy chained while powered by 4.5V. Moving forward, I’d like to do a rework on the display by daisy chaining all the chips. I did a back of the envelope calculation and found that the bus needs to operate minimally at 19.2khz to render the entire display without aliasing at full resolution and color depth which is well within the realm of possibility. I may forgo using one of the colors though to minimize code complexity and increase reliability. Another calculation I need to do is a worst case power usage estimate and to source a high current 5V supply. Hopefully I can use one of these old USB cell phone chargers I have laying around because I want this to be a standalone device.