That's not my intent. Your point is clear!


What's overmultiplexing?


Are you sure it's mandatory? The commercial signs I've seen (not recently) use current-controlled anode drivers.



Maybe so, though I think he wanted something relatively small, as for countertop use. He didn't say, though.

You've made it abundantly clear that the easiest way to get to where the O/P wants is by building a static (non-multiplexed) display.

Per has made it equally clear that he believes the most effective way to "get there" is by multiplexing rows.

I mentioned the CRT interface in the context of devising a functional "circular buffer", though Per thought I meant the pixels had to be muxed in that way.

We've discussed a wide range of issues ranging from packaging to power.

You and Per have favored the integrated IIC-interfaced current-controlled cathode drivers whereas I've advocated for garden-variety registered-output shift-registers and current controlled drivers to either Anode or Cathode, principally for cost reasons.

When you refer to his "sign", do you mean http://www.8052.com/forum/read/162729? You did notice that that's 6 rows of 7 columns per character, right? It's not a big deal, but implies there really exists no "sign."

I think he's still stuck on the notion of a circular buffer. Someone needs to explain to him that that's how he has to manage the characters, and, ultimately, the LED's (pixels) in each row, yet has nothing to do with his static-display or multiplexed-display choice. It's just a mechanism for scrolling the display.

There is a schematic out there somewhere ... Did yuo mean the one in
http://www.8052.com/forum/read/163134 ?
It has at least one weakness, namely that the shift registers are not output-registered. That means that he has to clock the bits into the register and then blank his display while he updates it. Now, the '164 can be clocked as fast as the 805x cares to clock it, and might even work fine using the UART in Mode 0, but even that would be slow, leaving the display blanked for an objectionably long time. (at least 80 but probably many more, microseconds).

As for the debate over how to drive multiple LED's per pixel ... Yes, the series-connected LED's work fine, but require distributing a higher-than-Vcc supply. For a sign that has to be visible from across a Bingo Parlor, multiple LED's are needed both to make the pixels large enough and to make them bright enough. Modulating the brightness with timing works but doesn't do it any "better" or more easily than using multiple drivers, though the discrete drivers do take up space and require I/O bits. If you use externally memory-mapped hardware (there really wasn't another option in '88) it doesn't matter so much. On a somewhat larger than 1-meter square sign, real estate isn't a problem either. I didn't say it was a great idea, but it does work with a single-supply board, though it requires a really hefty power supply. I readily agree it could well be better to use the multiple supplies rather than the multiple drivers. It just shows there's more than one way ...

In the case of this particular thread, I think a little more attention should go to the business of scrolling, since the lower-level details have been covered. The horizontal scrolling works easily with a non-multiplexed display. Per has pointed out that scrolling can make the characters "italic." If one multiplexes the rows, bottom to top when scrolling toward the left, that would probably be the case.

As you know, I disapprove of providing "canned" solutions. As a consequence, I think it reasonable to have on file, a schematic that shows a reasonable non-multiplexed display, with pseudo-code to demonstrate how the scrolling would work. Further, I'd consider it reasonable, too, to have on file a schematic of a row-multiplexed scheme as Per has suggested, with timing parameters to show how the multiplexing and update interact. I believe it should be left as an "exercise for the student" to work out how to integrate the multiplexing and the scrolling.

RE