| ??? 11/09/09 01:17 Read: times |
#170579 - Why multiplex ... there are so few words ... Responding to: ???'s previous message |
Per Westermark said:
Richard Erlacher said:
How, exactly, would you apply an 8x8 matrix display of the type Erik suggested to this problem? Are you assuming you can drive each LED independently? Just how would you arrange that? How many I/O's would it require? What other hardware?
This sort of clock uses words rather than characters, wouldn't you say? After all, it will say, "It is FIVE PAST FOUR", or "IT IS TEN TILL SEVEN", so the "IT IS" occurs quite frequently, while "NOON" may not occur so often. How do you see the row/column organization of the 8x8 matrix working in this application? How would you adjust the brightness? I am expecting a student to be able to figure that out. You should be able to figure it out too. We all had exposure to your thorough exposition of how to mux a moving display, so I'm sure that's (a) well-understood and (b)not particularly applicable to this problem. Driving row/column-connected diodes is no harder than when creating a "moving" display. The only difference here is that the bitmap to emit only changes every 5 minutes if the four corner diodes are separately driven. Once/minute if they are part of the LED matrix forming the backlight. Where you lose me is in the notion of a bitmap. Perhaps it is applicable, but since I believe the longest word to be eleven, assuming, for now, that there's to be 12-hour, rather than 24-hour display, no more than three LED's should be needed to illuminate that word, and fewer for most others. Since few words would be displayed, I see no need for multiplexing. Do you? Using four 8x8 modules would require a maximum of 16+16 signals if accepting a bad 16-to-1 multiplexing. A more reasonable multiplexing would need a maximum of 32+8 signals. the 8 signals can be reduced to 3 with a 3-to-8 decoder.
But a 16x16 backlight is bigger than needed so it will be enough to worry about the 11x10 part. The display could then be controlled by 20+3 signals (20*2^3 = 160 diodes and we only need 110). No problem for a normal microcontroller, so it should be possible to manage without any shift registers and clocking of the data. All the microcontroller would have to do is drive two "scan-lines" for 2ms before switching to the next set. That would give 100Hz refresh rate. Trivial code. Small code. Small CPU load. Exactly what problems do you see? A student don't need to bother with constant-current drive. Having enough voltage to burn over series resistors will reduce the variance in current depending on the Vf of the individual diodes. If you forget about multiplexing, as it's not likely to help, the code could easily take less than 1 kB of space and the static display would simply have to be updated minute-by-minute. RE |
