[Contest] RIOT Clock

[Michael]

I wonder if a Charlieplexed matrix may be of any use? Plenty of info' available on the 'net so I won't take up bandwidth here (and I'm terrible at describing things). However, it does provide an interesting way to drive the 2-pin Red/Green style LEDs (red, green, yellow?)...

[Dr Jefyll]

Chromatix wrote:

One of the things that LEDs don't really like is being held in reverse bias for long periods of time. Driving them directly between a '138 and a '238 would keep them in reverse bias about 7/8ths of the time.

Alright, a '238 (with its active-high totem-pole outputs) could be paired with a 74LS145 or similar (with active-low, open-collector outputs). Maybe there's away your chime circuit could work with this, too... ? Just a suggestion.

PS: Michael, cool stuff!

[Michael]

I found a picture of those Red/Green LEDs though the colors always seem washed out on my camera.

I like Dr Jefyll's '238 + '145 suggestion. I seem to recall the 'LS145 could sink something like 40 or 80 ma current. Reminds me of the KIM-1 display, though the '145 isn't being used as a sinking column driver there...

[Dr Jefyll]

Michael wrote:

Reminds me of the KIM-1 display

Owning a KIM-1 is what made me aware of the '145.

[Chromatix]

In this case, I think it's actually easier to use the normal NxN matrix method rather than Charlieplexing. I only need one LED in each ring lit at once, and Charlieplexing requires being able to tri-state individual pins as well as driving them in either direction, which effectively requires two bits per pin, which is actually *more* data to get off-chip to the driver circuits. This also avoids the need to reverse-bias some of the unlit LEDs.

Amusingly, the Wikipedia page on Charlieplexing shows a clock with a circular array of LEDs. However, they've done it with only twelve LEDs for the hours; natural hand movement requires fitting more.

[Michael]

Have you decided how many LEDs you're gonna use?

[BigEd]

Chromatix wrote:

One of the things that LEDs don't really like is being held in reverse bias for long periods of time.

Hmm, this surprises me, because Charlieplexing is often used in a hobby context. (And also because LEDs are diodes, so, without the benefit of extra information, I would have thought they dioded reasonably well.)

[Chromatix]

They do function as diodes, but their reverse breakdown voltage is relatively low, and apparently they degrade over time through metal migration if they spend a lot of time in reverse bias. I note that the Charlieplexing wikipedia page talks an awful lot about LED failures (both open and short circuit) and the effects it has on a Charlieplexed display, whereas my experience of LEDs is that they basically never fail when used competently; they may dim a little bit with age, but that's all.

I think it makes sense to fit 60 LEDs in each ring, one per minute mark on a normal clock face. This means the hour "hand" gets to advance by one LED per 12 minutes. There'll be some character displays as well for the date and alarm/timer displays, and some fixed LEDs to outline the ring and the hour marks.

[BigEd]

I noticed that too! But it looked to me like a typical Wikipedia fight, not necessarily a considered opinion. In other words, I projected my own complacency onto their agitation!

[BillO]

The ICM7218 can control 64 LEDS independently. It handles current limiting and multiplexing for you and is 6502 bus compatible.

Seconds and minutes could be done on the same ring. It would be obvious which dot was the seconds and which was the minutes. Hours would only need 12 (or 24 LEDS) and could be on a smaller concentric ring. Doing this you could get by with only 1 ICM7218 for the minutes and seconds hanging it off the CPU bus, and the hour LED ring could be controlled via one port on the 6532.

[John West]

BigEd wrote:

Charlieplexing is often used in a hobby context.

A lot of dubious practices are often used in hobby contexts. Sometimes because the people doing them don't know any better, sometimes because it's easier and reliability is not a priority.

I checked a few random LED datasheets from different manufacturers. They all have 5V as the absolute maximum reverse voltage. For that reason alone, I would never use this technique in a 5V system. Cree's datasheet (C503B-BCS, blue and green 5mm LEDs) went further and had a warning that continuous reverse voltage can damage the LED.

Doesn't Charlieplexing rely on the LED forward voltage being more than half the supply? If you're running at 5V, that rules out red, yellow, and some green LEDs.

[Michael]

Gosh, there's so many ways to drive a bunch of LEDs. With only 3 LEDs on at one time you could easily mux' a small matrix at a nice leisurely 33% duty cycle using inexpensive serial-to-parallel ICs (and you might not need column or row driver transistors???). My MacMux method (example below) would re-task the row driver pins for use as a CLK and DAT lines to load the shift registers in parallel (a 6 channel SPI of sorts) during a short blanking interval at the beginning of each mux' interval (when PWM on RB0 goes high). The driver code was relatively small and fast, using only 24 PIC instruction cycles to load the shift-registers from an 8-byte mux' array, and a bit more code after updating the display (a 'data bender') to prep' the mux' array for the next mux' interval. With a MacMux driver and 8-pin interface you would only need three (3) shift-registers to drive 120 LEDs but I'm not sure how you might implement PWM brightness control on the 6507/6532.

Anyway, food for thought. Good luck on your project. Cheerful regards, Mike

[Chromatix]

The approach I'm currently considering involves a relatively inexpensive driver IC that provides 34 or 35 open-drain current sinks (depending on exactly which version). That's enough for 10 sinks per ring. I would then only need to provide 6 switchable sources per ring, and there would be no need for multiplexing or even limit resistors. Just lots and lots of soldering of individual LEDs.

Mind you, one way to improve *that* aspect would be to use LED bar-graph units. If I align one unit with each hour position, that gives two adjacent LEDs per minute position. More leads to solder, but less fiddly overall. For the smaller seconds dial, I could use just six units and one LED per position. This does however constrain the size and shape of each ring, and I'd have to mock it up to see if the resulting layout is aesthetically reasonable.

Since only one LED per ring is likely to be active at a time, probably the drive capability of a standard logic IC is sufficient for those sources. Since the sinks are current limited, the voltage drop will be in the driver IC which is designed to take the load. The reverse bias over unlit LEDs in the same sink-group as a lit one will be equal to the forward voltage of the lit LED, which is much better than the full rail-to-rail voltage, and if a lit LED is open-circuit the reverse bias on the remainder drops to zero. But even this can be eliminated by retaining the drive transistors on the sources.

[Dr Jefyll]

Chromatix wrote:

[...] a relatively inexpensive driver IC that provides 34 or 35 open-drain current sinks [...] I would then only need to provide 6 switchable sources per ring

And this driver IC presumably inputs its data serially -- an entirely viable approach. Maybe I would've gotten around to suggesting this eventually, but you & Michael beat me to it.

Chromatix wrote:

[Driving LEDs] directly between a '138 and a '238 would keep them in reverse bias about 7/8ths of the time.

Here again I've been a little slow. Instead of '138 / '238, or even '145, I should've suggested that you consider using the 74CBT3251 1-of-8 FET Multiplexer/Demultiplexer. A device like this can be used in either a current-sourcing or current-sinking configuration, and all unselected pins are high impedance, as desired.

Best of all, you can attach the common node ("A", pin 5) to an intermediate voltage of your own choice -- IOW it's not an all-or-nothing decision of 0 volts or +5. (AIUI this version can't quite pull all the way to Vcc anyway, only to one threshold voltage below; but for driving LEDs that shouldn't be a problem.) You'd attach the common node to whatever supply you deem appropriate. Besides limiting current, you could also limit voltage, thus granting a safety margin in regard to the worrisome LED reverse-voltage spec mentioned upthread.

This device might also deserve consideration as the "6 switchable sources per ring" mentioned in the quote above.

-- Jeff

PS- FWIW, the other version, 74CBTLV3251, can pull all the way high or low, thanks to the use of complementary FET's. But the LV version is not rated for 5V operation.

[Chromatix]

Ah yes, I'd forgotten about the analogue versions of the multiplexer chips. But rather than the 3251, I'm thinking of the 4x51 series, which is available in the 74HC(T) series and is thus 5V compatible. I think one of these can also replace most of the discrete transistors in the chime circuit, and I might be able to replace the remaining one with a Schottky diode.

A particularly interesting member is the 74HCT4351, which has latched address lines. This eliminates the need to introduce extra ICs just to latch the select data. The digital-mux equivalent with latching is the '137.

So now I think I can hang both the chime circuits and the high-side display drivers off Port B of the RIOT, bit-banging a small parallel data bus to these latched multiplexers. This leaves Port A free to run the low-side and character display drivers on a serial bus, and receive button-press data.