Tuesday, November 28, 2006

The Serial Digital Medal Design


So I mentioned before that, to reduce cost and pin count, we were changing the digital medal design over to some serial driver chips. I'd like to talk about the new design a little.

The big cost saver is the ability to use the ATtiny45 (2.13USD Qty: 1) instead of the ATmega32 (8.28USD Qty: 1). Previously, the driver chips that we were using were really just gangs of transistors. Each transistor had an input and output pin. Hence the MCU pin count requirement to operate the chips was high and forced us to the ATmega32.

After some searching our members came up with transistor arrays that, instead of individual transistor inputs feature a clocked serial data input line that feeds into a shift register and a strobe line that latches the shift register bits up to the (now internal) transistor inputs. Additionally the chips feature a serial data out line that leads away from the far side of the shift registers. The source driver, U1 in the schematic and used to select rows in the 5x7 LED matrix displays is the MIC5891. The sink drivers, U2 and U3 in the schematic, used to select columns, are two A6821's.

So in the new design the three driver chips and the MCU are daisy chained: Serial Data Out connects to Serial Data in, one chip after another with common clock and strobe lines. From the point of view of the MCU this forms a single shift register that is 24 bits wide. The first two bytes shifted out become the column selectors and the final byte becomes the row selectors. The idea is for the MCU to clock out three bytes, hit the strobe and then repeat. This basic scheme uses a mere three pins to reset the state of all row and all column selectors and is why the ATtiny45 will work.

Of course, this is just the design. I have the circuit fully breadboarded up and can see the clock, data and strobe lines popping away at the first chip in the daisy chain, but nothing is coming out of the other side of the shift register on its Serial Data Out line. Most likely this mean that something is wrong with the clocked data that the MCU is emitting and thus the first chip isn't properly receiving the data in the first place. I only own voltmeters so it is hard to tell what is wrong with the signal. I've ordered a cheap O-scope/Logic Analyzer from Hobby Lab that should help me out. It should present me with timing diagrams of the signals on clock, data and strobe lines that I can then compare to the example timings in the data sheets for the chips. Hopefully there will be something I can do to correct the signal. My concern is that since I'm using the Bascom Shiftout command, that the only solution will be to shift to C for greater control of the timing. Maybe it won't suck too bad if I really do have to port the code though.

No comments: