We used shift registers all the time for CRT displays. One would load a character from the refresh RAM into the registered character generator and after suitable propagation delay, or, perhaps, one character clock later, load the resulting character generator output, derived from the row count and the ASCII code into a 74165-type shift register, the output of which was the video pixels. These were then ANDed with the dot clock and sent to a video combiner.

To do the same thing that was done with the CRT, one would use eight shift registers and load each of them with eight different row counts, then drive eight columns of the display matrix at one time. That makes little sense in this case, as it would demand lots of current and provide little benefit.

I suspect the O/P is using this sort of matrix, perhpas not bicolor, however:

http://www.sure-electronics.net/DC,IC%20c...-MM103.pdf

If this has "typical" sorts of LED's in it, it takes somewhere on the order of a microsecond for one of them to come to full brightness, once the current is flowing. Frankly, I don't know how long they take to decay to where they're no longer visible. Obviously, this sets a limit on how quickly they can be multiplexed. Another factor, a human one, is how long it takes the human eye to detect their activity, both in turn-on, and turn-off. If they're scrolled too fast, they'll appear smeared across the array.

From his original post, I guess he's using 20 of these matrices, hoping to produce 2 lines of text. That means he has to figure out how to drive his 80 characters onto a 10-character field comprised of 80 columns of 16 rows (He did say 16x80, didn't he?)

If he's driving it pixel by pixel, that means he needs to drive each of the 1280 pixels to full brightness every 8 ms. One at a time would suggest about 6.25 microseconds per pixel. While that's probably achievable, it's quite a processing load for a typical 805x. I can see why you might want to use an external shift register.

By driving columns, the O/P can reduce this processing burden, not only by reducing the amount of processing, since he doesn't have to isolate the row bits, but, he can use a column-per-character-per-column number lookup table to find a byte that defines the port bits that have to be driven and also allows him to reduce his scan rate by a factor of 16. It also reduces the external hardware demand, since he doesn't need to drive each pixel individually, but can drive them either 16 or 8 at a time, and at a pace that not only can be managed with a very minimal set of external hardware, but also is much more reasonable for the 805x, even at 12 MHz. He does have to drive 128 columns, so he has to demultiplex the column count. That requires 9 7445-type demultiplexers, one to demux the array address, and one to demux each array's column. A P0 and P2 buffer (probably a '374-type register would work) would drive the anodes, and the '45-types would drive the column cathodes. My old Fairchild TTL databook, IIRC, indicated, last time I looked, that the '45 could sink 64 mA. That's probably enough for 16 small LED's and they won't all be turned on very often, so it's really not operating at the limit.

The column counter is the critical element. It determines which column is being displayed and, each time its timer, the one that tells it to increment/decrement, sets the limit on how long each row is turned on. All that's required, timing-wise, is that one load the 80 characters to be displayed into a refresh RAM, probably an external one, start the column counter's timer, then fetch, from a lookup-table in code space, the column definition corresponding with the current character's current column and drive that onto P0. Then, the same thing has to be done for the lower line, which is driven by P2. P1 can provide the array address and the column count within that array for the 7445-type demultiplexers.

You can see how this works out. Since there are 80 characters to display, firmware moves them around in the display buffer, to correspond with the line on which they are to be displayed, if that's desired, else the display simply runs two lines at once. Each time the character counter overflows, the scroll counter is incremented/decremented. The maximal value of the scroll counter is what sets the scroll rate. To scroll to the left, it is a down-counter. Those of us who read/write from left to right will probably find it easier to read text that scrolls toward the left. Others may prefer the other direction.

Note that driving this array requires external hardware to drive the anodes and cathodes, but nothing to perform parallel/serial operations or lookups, e.g. the character generator. By driving columns, this is reduced in firmware burden, while allowing the 6.25 microsecond per pixel to be increased to 100 microseconds per column. That's a pretty generous time window, yet it fits that 8 ms limit of which Erik wrote in another thread.

I don't know what your managers think about using more external hardware rather than less, but the ones with whom I've dealt generally like the MCU to do as much as possible. I suspect that a standard 805x at 12 MHz may still not have much time left to do lots of other tasks, though there is quite a bit, but switching to a one-clocker would multiply that by about 12. That's largely a business decision, and not one left to engineers, in general.

RE