A normal CRT has, by comparison with LED's, a blindingly fast phosphor. A 50 ns pulse will put a bright spot on the CRT, while a 5 microsecond pulse on an LED will be imperceptible. Yes, I know, it takes a number of short pulses to make the thing appear "really bright." It's the same way with a light-emitting diode. The LED, however, doesn't do much at all with the 50 ns pulse, while the phosphor accumulates it. The dot on the phosphor doesn't go away right away, either, but it does decay quickly enough that one knows that it's gone. I remember, once, several decades ago, that I modified a black and white TV set for use as a monitor, and found that the horizontally "smeared" lines resulting from over-bright adjacent pixels looked better when ANDed with the dot-clock that drove the shift register that produced the pixels. This meant that every pixel was half-a-clock long, irrespective of whether it was alone or part of a string. The contrast of the display was, therefore, lowered and much more uniform. The conclusion to which this leads is that that CRT phosphor and LED's have quite different characteristics, and the designer of a display that uses them must be acutely aware of what the relevant characteristics are.

Now, Erik Malund, one of whose jobs is designing and implementing displays, many of which use LED's, on such places as public busses, indicating route and destination of that bus, to be read from outside the bus, is quite expert in such matters, and he's made it plain that people are able to detect "flicker" on displays that multiplex the entire visible frame at periods longer than 8 ms.

If I had to start on the design of a dod-matrix display, that I wanted to multiplex, column by column, since the sign is apparently going to be a linear array of 10 8x8 (a common matrix size) characters, and onto which I wish to display 80 characters, using a horizontal scrolling (either right to left, or left to right) method, I'd start with that notion, and it would inevitably lead me to believe that I had to display each column of eight pixels, for 100 microseconds. I would NOT attempt to multiplex the individual pixels because the current required to illuminate the LED sufficiently would probably exceed the tolerance of (a) the LED, (b) the driver, and (c) the column sink. Further, the timing would probably rule that out anyway. If it's using Roman block lettering, it would probably allow that one column of each character, not of the display matrices, but the character array, would be blank. If the characters were Arabic, or some other alphabet, perhaps that would not be the case. However, each such character would have be defined as a matrix of 8x8, or, at least, 8 Vertical x 7 Horizontal pixels. Printable ASCII characters in Roman alphabet can be so defined. Therefore, given a count ranging from 0 to 0x4FH (79 decimal) one count for each column, I can reliably turn on the sink for each of 80 common cathodes, or the source for each of 80 common anodes, for a predetermined time, not exceeding 100 microseconds. The LED has to be chosen such that it is bright enough in 100 microseconds, that there is no doubt that is is "ON" at full desired brightness. That brightness can be moderated by shortening the 100 microsecond "on" time. The 100 microseconds would have to be regulated by a timer in the MCU. When it times out, I'd have to fetch the next character to be displayed, look up the current column count, and fetch, from code memory, the value of the current column in the currently displayed character and writing it to the port that drives the column anodes if it's a common-cathode array, or the cathodes if it's not.

I'm sure you see how this progresses.

Horizontal scrolling is simply a matter of incrementing or decrementing (depending on direction) the column count by 1 at the beginning of each displayed frame. If there is "smear" between adjacent pixels, then the current has to be turned up, and the on-time reduced. This is a product of the interaction of the drive circuit and the LED choice. If the LED has been chosen such that its intensity rise and fall rates are sufficient to allow the display to be operated at a 50% duty cycle, then smear should not be problem. If the overall intensity of the display in the ambient lighting environment is at maximum, the scroll rate may have to be moderated. This can affect readability, since people want to remember the entire character and will have difficulty with columns.

I fail to see the advantage of the shift-register approach that you've mentioned, Per. I don't see a timing advantage, nor do I see a firmware advantage. Perhaps you're using a different sort of display.

RE