| ??? 03/14/09 13:10 Read: times |
#163452 - It doesn't HAVE to be done in a conventional granularity Responding to: ???'s previous message |
Per Westermark said:
Richard Erlacher said:
It seems to me that he's driving rows with a current limited by the resistors R1..R8 This post indicates that the OP has now moved the resistors, based on a number of posts that they were incorrectly placed in the row drive instead of the column drive: http://www.8052.com/forum/read/163333 I missed that. The current requirement and forward voltage for his particular LED's has, so far, been omitted. That doesn't matter. If he looks up those spec's he can make his own calculations. Erik seems to think he's just been guessing. The problem is still that:
1) The new resistor value might not be the best. 2) The OP have not tried a minimalistic output code to just light up the display, without bothering with any bit-mapped data, to verify the hw function. Richard Erlacher said:
consider driving 10 cathodes rather than one column But the multiplexing scheme is never used to drive one LED unless the goal is that the display should only show one single pixel lit. It does not drive 1 LED. It does not drive 10 LED. It drives 80 LED or 240 LED or 960 LED or whatever length your shift registers are. I don't follow ... Couldn't one further multiplex the LED's in a row, driving 1/8 or 1/4 of them at a time, if one wished to do so, assuming that the LED's are bright enough to allow it? The granularity at which one multiplexes is generally determined by what's convenient and fits the timing. I see no reason why one could't split the row into smaller segments or multiplex using multiple columns at once. For each SIPO chain, and you may have many shift register chains so the processor may shift out data a byte at a time into eight chains or two byte at a time into sixteen chains, and each chain is responsible for a large number of diodes. The special case is of course when all the SIPO chains fully spans every single pixel, in which case the display is fully DC-driven.
A multiplexed sign need not be limited to a 8:1 multiplexing factor. You may have a 16:1 or 4:1 or 2:1 multiplexing factor or even odd factors like 5:1. A lot depends on form factor and intended use. And don't focus so much on rows and columns. A sign need not be ten times wider than it is high. A lot of LED signs are used for symbols and other special applications in which case smaller PCB panel blocks may be oriented in different directions or maybe even zig-zag logically. A multiplexed sign is a concept, but that concept can vary (just as you can switch if you source or sink the columns) depending on need and requirements. But the reason for row/column is of course that rows and columns are easy to CAD when you do the PCB. A multiplexed sign with a zig-zag pattern within the panel would have a hard time to chain together all diodes controlled by a shift-register output, and/or all diodes controlled by a source/sink transistor. But think about it: Two SIPO lines driven at 1MHz would consume 80us for the data to 160 diodes and 640us for he data to all lines. At 1 MHz, I think it would take at least 160 us with a single channel. I think that assumes facts not (yet) in evidence, i.e. I believe the O/P indicated he's using an 11 MHz-clocked 12-clocker with no built-in hardware for SPI or IIC. If he bit-bangs his SIPO interface it won't go that fast, and, in fact seems to me it will take closer to 15 microseconds per bit to clock out the data. He has to count bits, raise and lower the clock bit, figure out where he is in his display procedure, look-up and isolate the data bit, etc. The remaining time until a frame switch can be spent figuring out what to display next. The only problematic thing in this special case is that I guess the OP has a 12-clocker which does affect the output speed. And lack of memory may require that the program has to think about what to emit while emitting it. Having a shift register without latch will then mean that the output-enable will have to be deactivated for significant time when computing/emitting the next scan line - or all "off" diodes will glow while "on" bits are shifted past their position. This may not be an issue for scrolling, but it is an issue for serial updates. The SIPO register should be output-registered in order to mask the update time. The slower the MCU, the more important this is. Real-world signs are designed based on what is practical, which means that you in theory can come up with a number of other alternatives that have been already rejected. It's important to know why they've been rejected, and, in some cases, why they are rejected under one set of circumstances, yet quite useable in another. Richard Erlacher said:
That way you can work at a frame rate more tolerable than one LED at a time would allow. Since the processor works a scan line (or full sign for DC-driven) at a time the frame rate is just a function of how many bits you may send out per clock pulse and what clock rate you may use. Since it has already been established that the display does not show a diode at a time, the possible frame rate isn't affected by the LED count in this way. The maximum frame rate is controlled by how fast the processor can build the bitmap (either fully pre-built or built on-the-fly when sending out the data or by clocking data into an external character generator) and how fast the processor (or external character generator) can fill the SIPO. But it has already been established that the CPU don't have to be limited to a single SIPO chain spanning 80x16 diodes. A fully DC-driven sign could be built with a single 1280-bit SIPO. But the only gain of such a design would that it would be enough with a single data-out pin on the processor (maybe used with hardware SPI or similar for off-loading the shifting at 20MHz+). In reality, larger display controllers would support many SIPO to keep down the number of clock pulses required to fill a scan line or the full sign. Not unlikely one SIPO / scan line, in which case the OP display would be fully clocked out in 80 clock pulses - something even a 12-clocker would do quite quickly and then have almost 8ms available for thinking about the next frame. Since the O/P has defined his MCU, it's pointless to wander off into what "could" be done if he had resources that he doesn't have. A DC-driven sign would be just as well driven from a memory-mapped parallel-interfaced set of octal registers as from a SIPO configuration. It would benefit from greater parts availability at the same time that it reduces the low-level firmware burden considerably. The first indoor countertop scrolling LED-based sign I saw was a one-line display about 5 cm high, equally thick, in a package about 30 cm long, operated by an Intel 8049, operating at nominally 6 MHz. That means it executed one instruction in 2.5 microseconds. IIRC, it had 1 KB (2 2114's)of external RAM. Clearly the task doesn't require a 5 GHz CPU with TB of RAM, and lots of specialized hardware. Protocols such as IIC or SPI don't make the task quicker and easier, either. It's simpler to write to a port and know the data has arrived at its intended destination. Even a serialized interface doesn't require a complex protocol. To save space, it might be desirable to parallel load a PISO register and have it shifted out to its destination in serial form to registered SIPO registers, but using a complex protocol designed for more complicated operations is not always helpful. A multiplexing scheme doesn't have to be limited to using individual LED's, rows of LED's, or columns of LED's, nor does a display have to be DC-driven if none of those options are deemed acceptable. Multiple columns, segments of rows, or other arrangement of pixels could just as well be found workable. Hazards are flicker and inadequate brightness. Those have to be taken into account. Filters can help considerably with contrast. RE |
