Allegro LED Drivers
I ordered a handful of A6276 16-bit LED driver sample chips Friday. If you look closely at the construction of the CK-3000, you can see that they effectively use three LEDs in a row for each segment of a seven-segment display. That makes a total of 21 LEDs in a digit, plus 2 for an inter-digit colon and 1 for a decimal point, for a grand total of at most 24 per digit. Sounds like a 16-bit driver plus an 8-bit driver, or sharing three 16-bit drivers across two digits.
Font Decisions
So if the LEDs are just grouped in threes to make up a seven-segment display, why not use a seven-segment display driver and save the hassle of a 24-bit driver? Because I’m utterly enamored of the idea of making the digits as perfect as possible within a 5×9 matrix. So when it’s time to make a 3, I don’t want to do this: 
I want to do this: 
I drew up three sets of fonts to represent different LED-driving strategies.
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
The first font is what you get by driving each strip of three LEDs as a segment in a seven-segment display–all three in each strip are on or off at the same time. (I assume this is how the CK-3000 works.) This would take 21 LEDs and seven drivers for each digit. To me, this looks even worse than a standard seven-segment display, because the corners are missing. Normal seven-segment displays have the segments “mitered” into the corners, but this has a gap in each corner.
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
The second font is what you could get using the same LEDs, but with a separate driver line for each LED. It still has 21 LEDs, but each LED can now be controlled independently.
With independent control of the LEDs, I was able to “round out” a couple of the digits–particularly the 3. I like the way the 3 looks, but the contrast between the good 3 and the bad 4–or between the top and bottom of the 2 and 5–makes this an even worse choice, in my opinion.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
If I’m going to bother making a clock like this, I want it to be as close to perfect as possible. The third font uses more LEDs than the CK-3000: 28 LEDs, to be precise. It uses the original three LEDs for each of the seven segments, plus fills in each corner (see especially 4 and 7; as well as 1, 2, and 5) and the middle of each edge (see especially 0 and 1; as well as 4, 5, 6, 7, and 9).
Finally, it adds one extra LED inside the perimeter of the lower half to round the lower curve of the 2. It’s a small thing, but it transforms 
into .
Drivers Redux
We’re now up to 28 independently-controlled LEDs per digit, plus optionally two LEDs for colons and optionally an LED for a decimal point. At 31 total per digit, it sounds like two 16-bit LED driver chips per digit, or twelve to sixteen for the whole clock (depending on whether it has a hundredths display).
I’ve been thinking about how to connect the chips to the microcontroller. They’re serial-in chips, so at one extreme, I could string them all out in a giant line and shift all of the characters’ worth of data every time there’s any change. That means that every second, I’d be shifting out another 192 bits of data, which isn’t bad–just annoying. Or every centisecond, I’d be shifting out 256 bits, which is even more annoying.
At the other extreme, I could connect each character’s 32-bit (two-chip) driver to a separate set of pins on the microcontroller, so each character was individually addressable. Since each register needs a minimum of three signal lines to operate (serial data in, clock, and latch), that’d be eighteen signal lines coming out of the microcontroller–which I don’t have enough pins to do on the PIC18F2320, and I’d rather not have to use a PIC18F4320 just to have enough ports.
I could also split the display into smaller serial chunks–for instance, dividing between character pairs (HH : MM : SS) would only require nine signal lines. I could matrix the display, using a combination of source-selection and sink-selection to strobe each character’s worth of LEDs rapidly in sequence. And I could address the driver chips out of the microcontroller, to matrix on the logic side rather than power side; this would require demultiplexing and fiddling with their clock inputs, since the A672x chips don’t have enable inputs per se.
To keep parts count low, and for the sake of simplicity in the software, I’m actually leaning toward the all-serial solution. Yes, it spends a lot of time bit-banging LED data out the ports. But the trade-off is not having to add extra chips for matrixing, and not having to determine in software which characters need to be updated. The software can simply determine the current time and pump the whole thing out to the display.
Of course, I reserve the right to reconsider after I get the chips and start playing with them.
