| ??? 03/14/09 15:24 Read: times |
#163455 - consider ALL the alternatives ... Responding to: ???'s previous message |
Erik Malund said:
There are other ways, too, to reduce the complexity of the multiplexing scheme than just muxing either rows or columns. Just for one example, consider driving 10 cathodes rather than one column. Most MCU's can manage that. That way you can work at a frame rate more tolerable than one LED at a time would allow.
get your head out of your .... with the exception of your irrelevant reference to CRTs there has NEVER been ANY reference to "one LED at a time". I'm not so sure I'm the one with the cephalorectitis in this case. You seem to believe that (a) there's no way to do this job without shift registers. That's certainly a major mistake. Secondly, you seem to believe that there's no way to do this without using current-controlled cathode drivers. That's certainly a major mistake. You seem to believe that the anodes can't be the source of the controlled current. That's certainly a mistake. That's not to say there's anything wrong with the way you suggest, but it's certainly not the only way. I brought up the CRT interface as an example of a recirculating shift register. It's not the only way in which that could be applied to this problem, but the CRT adapter has all the elements. It has the raw character message storage, it has the character generator, it has the timing logic, and it has the entire character-to-pixel-stream translation scheme, not in a form one would be likely to use for this particular type of display, but it embodies all the concepts. If the O/P had been willing to do the underlying research, which would have taken perhaps as much as a half an hour, he'd have understood what has to be done. from the VERY BEGINNING everybody that has even an inkling of understanding what is discussed has discussed one row at a time. Which seems to suggest that, while they may have an inkling, they have failed to consider all the options, thinking, instead, that THEIR way was the only way. There's no reason this has to be done row by row, just as there's no reason it has to be multiplexed in columns. The SIPO approach is fine if you have only a few pins available for the I/O, but since this involves a dedicated MCU, He can drive the two lines of 8 LEDs at a time each with a buffered parallel port and sink them column by column or in groups of three, seven, ten, or any number of columns at once, or whatever else he likes. He doesn't have to do what you prefer, nor does he have to do what anyone else might prefer. What he does have to do is to figure out what's necessary. Apparently, though, he hasn't done that. Erik We're dealing with an O/P who wants his thinking as well as his work done for him. The key to doing this job is not merely how to drive an LED. This is a system-design problem and the O/P has determined he wants to use an 8x8 LED array and an 89S52 MCU. Beyond that, he's said nothing about what he's actually using, aside from a reference to the 4094 type register, which, actually is not up to the task without a hefty driver, so he added a ULN2803A with which to drive the columns. He's said nothing about the LED's he's using. He's suggested a couple of R-values but didn't say why he wants to use 'em or how he arrived at 'em. Nobody apparently knows what he's really doing, and, more importantly, whether he's doing anything, because no specifics have been mentioned. How he drives his LED's doesn't matter, so long as he does it. He doesn't specify how long he has to leave his LED's turned on, and nobody can make a really useful guess, not knowing his LED. He hasn't indicated what his target environment is, i.e. indoors with normal room-lighting, lab with suppressed room lighting, outdoors in direct sunlight ... or even how large he wants his sign to be (60x20 meters, or 20 x 600 mm). We all know that you're an expert on at least one type of sign. You've made it plain that you dislike multiplexing. Surely you know that there are justifications for multiplexing, but multiplexing is just another option that has to be considered in figuring out how to design the O/P's sign. It would be helpful if you'd stop presenting a way in which the O/P should drive his LED's and present ways in which he could, leaving the option up to him to select. For you , it seems that there's only ONE compiler, and only ONE MCU, and only ONE way to extend I/O, etc. That may not be wrong, but it's certainly not right. It's only from considering ALL the available options that an optimal solution can be reached. That means considering and ruling out the things that won't work at all, as well as the ones that won't work adequately and knowing why they should be ruled out. If you can't do that, then perhaps I'm not the one who has his head wedged. RE |
