AVR Freaks

Heh - I was just reading the datasheet on the UCN5833EP. Same thing.

But that still requires at least 5 additional chips :( I'm very real-estate constrained for the control system - the LEDs are off-board.

I've never done (C)PLD work before. How hard is it really to generate custom logic like this ? I've found a couple of "tutorials" on PLD programming - I'll have to dig into those. Also, it looks like Altera makes their software available free, so I guess I'll look at them first.

Good on ya Altera :)

Dean.

This is actually for a five-arm rotating display - Similar to the propeller clocks that were all the rage a while back. The difference here is that it has to be able to display nicely not only at fairly high rpm (around 1000rpm) but also at low rpm rates, say 300rpm or so (5Hz). Hence the 5 arms rather than just one or two, that will give a better visual persistence. Might be able to get away with three arms though ...

The other is that I would like to be able to display more than just the time or words - so just 7 LEDs won't cut it. It looks like 35 or 40 LEDs per arm is about the bare minimum for anything decent.

I hadn't even considered mux'ing the LEDs, I've been more concerned with maximizing the on time for each time slot. How much of a brightness effect would mux'ing like this cause ?

Actually, here's another hassle I've been noodling - the data storage format. The simplest would be to store bit patterns for each slot or display-time-tick. That gives discrete "pixels" per se. Not too bad, but it could be better. Particularly since the outer LEDs will be individual-looking, while the inner ones will have lots of overlap.

That can be mitigated by dealing with them in chunks. Say the outer five LEDs have 360 slots or pixels, the next five in have 300 slots, and so on. Numbers here are for arguments sake :) I haven't calculated out all the best sizes yet, but I know how to do it this way.

Another method is to store on and off times for each ring in the display. Or one can think of it as a polar display, and store the start and stop thetas for each d.

Pulling bit patterns out of memory and twiddling them is pretty easy. But my head hurts when I think about how to arrange the data for the second method, and it really hurts when thinking about how to access it efficiently.

Lots of expertise in this forum - this is great :)

Dean.

Heh - wow again. Good discussion here.

Mike -

I'm not sure I'm following you here.

> For 5 arms to create a perceived monolithic display, the eye will have to visually > join the innermost led on each arm with the outermost led on any other arm, a > distortion of over 20 times what muxing gives.

What do you mean visually join the innermost led with the outermost ? I'm not sure I'm visualizing the same thing you're intending ...

I've also been thinking about the resolution of the display. The simple way is to have say 360 display-slots. 360 bit patterns to make up an image. Pull a pattern, display it for a length of time for that display slot, then the next, etc. But that has the afore-mentioned overlap problem - the outer leds have nice discrete individual appearances, while the inner ones all congeal into an overlapping blob. Could do it in chunks, as mentioned above as well. But I like your idea of treating each led individually. Same idea as chunks, just taken to the logical extreme.

That will definitely make the data format and storage/retrieval much more complicated though. The simple 360 way is easy : just pull bit patterns from memory and shift em into the registers. Each bit pattern occurs at a set time. But running each led/ring with an individual total "pixel-count" or on-off slots per rotation for the whole display, now that messes things up :)

Fake numbers here : You would have to retrieve led1 bit pattern every 200 ticks. leds2 would be every 203 ticks. led3 every 209 ticks. So we'll need a bit-pattern for each led/ring rather than a bit pattern for each display slot. Also a table to say how often (how many ticks per) to retrieve the next bit for each led/ring. Since rotational speed is variable, those will have to be virtual ticks, scalable to the current rotational speed.

At the start of each rotation load a table with the scaled tick counts. Then every tick, check against the table. Any match, go get the next bit for that ring and shift it in to place. Heh, maintaining the pointers and accessing the individual bits like will be messy.

OK, enough software ...

My original hardware plan was to have a PLD of sorts driving all the leds. It would consist of five individual 40bit shift registers with 200 output pins for the leds, 4 bits for register select, and a couple of pins for serial and clock in. The cpu would select register A, clock in 40 bits, select register B, clock in 40 bits and so on. Then it would sit and twiddle its thumbs for a display-slot duration, then repeat with the next slot bit pattern. Hrm - had forgotten to check on total power dissipation for PLDs. Probably couldn't handle 200 leds at 20ma each :) So, that plan is now discarded.

Now it looks like muxing is a much better answer. Rather than twiddle thumbs, it could use that time to cycle among the five arms. Set the leds up in a 5x40 array, clock in the arm A pattern, display it, clock in the arm B pattern, display it, and so on. Repeat until the display-slot duration expires, then retrieve the next pattern and continue.

So instead of a mass of pins, we wind up with a single 40bit register - two chips probably.

Getting there :)