Well, I’m having a some code-writers-block on applying data from the array to anything usefull… so I’m looking at ways to get more data from fewer and cheaper microcontrollers.
The cornerstone of led sensing is tristate logic. The PIC microcontroller can set each of its pins to high, low or neither (high-z). This is what allows me to forward bias, reverse bias and then sample the led. However, doing all of this requires a large number of pins on the PIC. Two pins are required for each LED. That’s why I did all this work on networking pics on a shared bus… but the cost of pics is pretty extreme, so I’m wondering about alternate ways of accomplishing the same.
Enter low-cost analog and logic interface ICs. There is a device called the 74HC573 octal tristate latching buffer. Basicly its a chip with 8 outputs, which can be high, low or high-z — same as the PIC. I really don’t care about the number of outputs, I plan to use a pair of them in an all or nothing configuration… tie all the data input lines together with a single PIC pin. I also probably won’t need the latching ability, but the 573 was cheaper than the 244 which is an octal driver without latching. So, the pic can control 16 led anodes with 1 pin – thats some awesome savings right there! 🙂 Next comes the cathode side, which is what the PIC reads with the ADC. For driving the cathodes, I plan to use the same configuration as the anodes, with the exception that I’ll also use the output enable line on the 573, to put the outputs into high-z just before sampling. All this leaves is the actual sampling. I’ll do this with a 16 to 1 analog multiplexer. The mux has a pretty high RDS(ON), something like 180 Ω … which is actually pretty close to the 150 Ω I’m using now. I figure I can put my resistor on the cathode side, after the mux connection, so when the cathode side driver is in high-z mode, my current limiting resistor disappears. In order to keep the array bright and eliminate any humans from seeing flickering, I’ll flash the entire row before sampling each LED. This should also give me the best conversion resolution on my leds, since the sampling time needs to be so high, I wouldn’t be able to read them all before their values changed.
By my calculations, scribbling in notepad, I figure I’ll need nine lines from the pic to control 32 LED lines (anodes and cathodes for 16 leds). Which is great, since I can use the lower-priced 18pin PICs… and it also sets the default row size to 16, up from the current 10. Of course, there’s no reason I’d need to do the full 16, but its good to have options! For the cost of one more pin from the pic (still easily within the 18 pin range), I could add another 16:1 mux, and lay 32 leds on a single pic! With the pic able to source and sink at least 25mA; it should be able to drive a ton of 74HC573s, which according to the datasheet need 1μA of input current per data line. Muhahahah! I’m not sure how many LEDs each PIC can handle and still have enough time to get a few complete collections inbetween servicing i2c interrupt requests with a 400 or 1000 khz bus clock.