Wagner Lipnharski wrote:
>
> Ok, now, don't forget about the LED intensity.
>
> Even if you apply twice the LED nominal current (the max peak
> recommended by the manufacturer), you can not make it bright enough to
> see at the day light if you apply current for less than 10% of the time.

Agreed

> If you are planning to time share current, in a scanning technique,
> remember this.
>
> My personal experiments with scanning display, ended in a maximum of
> 1/8, (1 on, 7 off), using 40% more than the nominal current, at a rate
> bigger than 200Hz.

Yep.. had to do the same..

> If you will build a display like that, I think you could go a little
> further, and do it not only horizontal shifting message, why not do it
> scroll vertical, or zooming, dropping, pouring, and sometihng like that?

Not difficult to do.

> The only trick here is to have a memory bit mapped space, and your
> processor can set or reset any bit into that memory. That block of
> memory is then sent (10 or 20 times a second) to the LED driver system,
> that will copy that to the LEDs, each bit corresponding to a specific
> LED.
>
> If you think about it, it is not that difficult.
>
> But remember about the scanning, a 80 x 8 led matrix would require one
> whole horizontal line (row) of LEDS turned ON all the time, so you would
> need a 80 drivers to constantly feed the columns.   Considering a 50%
> increase in the LED current, lets say from 20 to 30mA, you would need a
> power supply around 30mA x 80 = 2.4 Ampers, just for the LEDS consume.

I am doing that currently with a 16c66 running at 8Mhz.. Driving a 96x7
led matrix.
Using non latched shift registers (74164) from memory.. driving uln2003
darlingtion arrays thru 300Ohm resistors for the columns and the rows
driven from 2N2955 Transistors..
Because the shift registers are not latched, you must have the rows off
while shifing data in.. A pig of a design really, but it's someone elses
board and just my controller.
Using 96 bytes of contiguous ram for the display buffer, and most of the
remaining ram for comms buffers.. effects buffers and the like.
Everything is updated real-time and is commanded thru an rs485 link
at 9600 baud.
The display is refreshed thru a real time interrupt, and the serial data
to the display is bit bashed as the SPI and UART are mutually exclusive.
Also, given that each bit has to be masked from the relevant byte, it's
not that much quicker.

The characters are stored in lookup tables styled along the lines of
Don McKenzies old Z80 code. (Hi Don!) tho had to put them across 2 banks
so as not to cross a bank boundary... Bloody banks..

The Character generation routine is very very very tight hand coded
assembler, because when it is triggered after a display line refresh
it only JUST has time to finish before the next refresh is due. So
tight is the timing.
The display ram is locked by the char gen routines using a semaphore
to prevent the isr from touching it, should the char gen take to long.
Otherwise the display glitches and presents a tearing type of picture.

Anyway.. writing the code only took me about 2 days on and off, and
it was Hugely educational when it came to shaving 80 or so cycles from
routines to stop jitter and glitching..

The effects are the fun part.. Only completed the slide/wipe and roll
so far.. I'm looking at external ram for some more spiffy effects..
It's fun to see how far you can push a $13 chip, when your competition
is doing it with a full blown HC11 with 32K Ram & Rom at 16Mhz..
But then they will write in C won't they :p)

Cheers...
Brad...

PS. If you want to look at CHEAP, and very good led signs.. take a look
at what out South African buddies are up to. I have gotta say, those
years of trade embargoes have turned South Africa into a very clever
continent.