[Mike Shegedin] makes full use of an 8-pin microcontroller with this ATtiny13-based dice project. With a maximum of six I/O pins (that includes using the reset pin as I/O) he needed a couple of tricks in order to drive 14 LEDs and use a momentary push button for user input. We’re certainly familiar with the concepts here, but it still took quite a while to figure out what is going on with the schematic that [Mike] posted.
You’ve probably already guessed that he’s using Charlieplexing to drive more LEDs than he has pins. But when we started looking at the layout we thought he had drawn the schematic wrong, because there are six pairs of LEDs where the two diodes in each pair a not reverse biased, but hooked up in parallel. That, plus the fact that his battery is hooked up backwards. After several minutes of study the light bulb finally clicked on. Dice add pips (the dots on each side of a die) in pairs with the exception of the center pip. That means that you only need to control four total lines for each die (three pairs plus the center pip). There’s two ways to handle this, you could use four rows and two columns with traditional multiplexing, or you can reverse bias the two sets of LEDs for each die and use Charlieplexing. The former is a bit easier to program, the latter saves you one I/O pin and meant that [Mike] didn’t need to use the reset pin as I/O.
This is a clever addition to the collection of dice projects we’ve seen like the battery-less die, and the ATtiny2313 powered dice.
14 thoughts on “Two Dice, One 8-pin UC”
Nice to play monopoly :P
Why does the “fixed” schematic show the pin labelled VCC going to the -3v side of the button cell, and the pin labelled GND going to the +3v side of the button cell?
The old schematic here:
is identical to the new one, except the new schematic has added the word “Fixed!”.
I think the intention when editing the image was to horizontally flip the icon for the battery, but that step got lost when adding the text to the image…
Please fix the image before being start complaining about it not working (or worse)…
Many thanks to Rob for pointing out that blunder.
Regarding the center LED being brighter, I guess he could have addressed that in software to avoid the extra resistor. The code would be a little more complex, but not too bad. By changing the duty cycle of the center LED so that it is off more than on would have made it’s brightness more closely match that of the other LEDs.
Good point Tim. Doing it in software is certainly in the spirit of the project. Definitely on my list of “Things-To-Try”.
Every time a dice hack has been posted several people have pointed out how easy this implementation is. I even posted a link to a google books excerpt showing this.
Mike, you mention ghosting. Do you disable the common anode/cathode line (PB4) while switching between the pip outputs? That’s the most common source of ghosting. The common driver is still enabled when the new multiplexed output is switched in. Sometimes just for a machine instruction or two but enough to visibly light the LEDs.
DanJ — Hello! Good point regarding ghosting. In earlier stages of the software, I focused my efforts on the polling routine because the ghosting only occurred on the center LEDs, which share the polling line. And at some point it became clear that turning off all of I/O lines (setting them as inputs) before polling was the answer. Doing so eliminated the worst of the ghosting by far. Now it’s time to consider similar efforts even when the button is not being polled to eliminate the very last bit. Thanks again for the suggestion!
Quoting from the blog: “Haunted LEDs Perhaps due to the fact that all the LEDs are always connected, when a roll of 6-6 comes up, there is a bit of ghosting in the middle LEDs. I think this is just unavoidable in this circuit and is probably one of the reasons that people say hooking up LEDs in series is a no-no.”
What people are saying hooking up LEDs in series is a no-no? It has always been my experience series is vastly preferred to parallel for devices like LEDs.
Right again! I should have written “hooking up in *parallel* is a no-no”. And in this circuit, they are definitely hooked up in parallel. Probably not an issue as long as the forward voltages of the LEDs used are the same, right? I tried adding an additional LED (in parallel) to the center pips so everything would balance out. Of course that solved the bright-center pip issue completely, but, while improved, there was still the tiniest bit of ghosting remaining on the center pip on a 6-6 roll. So I think there might really be something to DanJ’s post above about shutting off outputs before switching. I’ll try that next.
Could this also be accomplished with a serial in parallel out shift register with output enable? This would merely require 3 pins, one for clocking the shift register, one for the data bits and one for output enable.
You could forgo the output enable pin in many cases because the shift registers would update so fast that you wouldn’t even see the data being pushed into the register.
Cool project — I like seeing people squeeze very high level functionality out of these kinds of chips.
Holy crap, that is crazy complicated. Awesome!
Please be kind and respectful to help make the comments section excellent. (Comment Policy)