Changes by last author:
Added:
|
Developer information
For some applications we want to drive several LEDs for displaying runtime parameters. The LEDs are usually arraged in a matrix form electrically (not necessarily on the display!), and driven multiplexed, to minimize semiconductor usage, and make operation somewhat more efficient (smaller dissipation on series resistors). ---- Common requirements for LEDcount * 3 digit 7 segment eats 3*8 with the dots (but common cathode usually?) * LEDbar_24 eats 3*8 That sums to about 6*8 .. 10*8 matrix in most applications. The software load for the multiplexed driving is noissue, handler2k has a few lines which supports the 10*8 matrix with about 100 Hz display refresh with marginal CPU load. ---- LED power We are concerned of * low cost LED driving for front-view LED displays (8..10 mA/LED) * HUD (head-up-display) very bright, high current drivers, so the reflection from the windshield is still bright enough (preferrably at daylight too? that's tough) ----- front-view LED displays * we can do simply using atmega8's outputs (tricky as Jorgen found out) and some low/high side switches. * http://www.national.com/pf/LP/LP3943.html http://www.national.com/ds.cgi/LP/LP3943.pdf LP3943 is a 16 LED driver (multiple programmable states-on, off, input, and dimming at a specified rate) with 16 Open drain outputs capable of driving up to 25 mA per LED: in fact 200mA sum means that for 16 LEDs max is 13mA / LED, still not enough for HUD. * 74HC259D used as direct (non-matrix) LEDdrive can do about 10mA per pin, costs only 0.1 Euro for driving 8 LEDs, footprint probably not optimal. ---- LP3943 for injector PWM-ing ? Are you, Keith, suggesting LP3943 for injector PWM-ing? Eg. if one wants different PWM percentages for his injbanks? GenBoard/VerThree HW supports 1 common PWM duty% (besides the 100% / 0%): should be perfect for any reasonable setup. I guess you suggest it for LED-driving... ---- HUD Head-up-display, requires * very bright LEDs (where's Jorgen's bright elfa link?). * powerful lowside switches * powerful highside switches * optional latch for one-side * optional demultiplexer or latch for other side The latch might be inside the driver, or might not be necessary, if the uC has enough outputs (8*8 matrix requires 16 outputs that way). [Osram] has some [Golden Dragon] high intensity LEDs which may be suitable for HUD use. They have some suggested drivers too. http://www.osram-os.com/news/news-BMW-Head-Up-Display.html has a description of BMWs 5-Series HUD display, which appears to use an Amber LED array behind a TFT screen. Use Chip On Glass (COG) graphical LCD with transmissive polarizer - white text on black background with a LED lightsource behind it would do. A quick overview of LCD options is [here]. This suggests FSTN display should be used, with a suitable display color provided by the lightsource. Doesn't have to be COG, but that technology offers nice packaging. A regular graphical or character display could be prototyped with a hacked up backlight. The 11000 mcd SMT LEDs used by BMW retail for $10 each, so possibly $0.50 7600 mcd SMT [LEDs] could be tried first... An example of an white text on black background:
We've located an LCD that is sppears to be suitable, the 13265-34-FN-M-ET-6 from Pacific Display (not the one shown above!). It's 132 x 65 resolution, it's got all the specs we want, and as a bonus it's got a controller with a serial data port. Bigger might be nicer, but this is a good starting point. I've waited 2 weeks and sent a follow up email after 1 week to get some action, but nothing happens. I guess Pacific Display doesn't want our business. Time to find someone else, maybe Hantronix or similar in Asia... Backlighting could get interesting however... The BMW unit appears to pack around 750 cd into it's 55mm x 26mm area. I think the best we can do without spending crazy money is about 300 cd (maybe ~400 if pushed) into a slightly smaller area. We'll be using considerably less power to do so, but heat is still going to be an issue. This 55 LED (11x5) array wants as much as 10 Watts, so the mounting might have to be creative. I don't think we'll get enough light if we stick to the recommended pads and spacing, so some kind of integrated heatsink/socket array might be in order. Here's an example layout. The LEDs cover the entire display area, with vias sinking to additional cooling area on the bottom layer - small heatsinks could be added to the back. Just don't ask me how to solder it...
The projection surface may need to be considered. Newer cars with HUD option, such as GM use a DuPont laminate for their projection. Some others use an adhesive glare reducing patch, but this may or may not be necessary. Word is that the Defi units look ok without the patch. Have to try it and see eh? http://www.dupont.com/safetyglass/lgn/stories/1004.html Aftermarket options already exist - http://www.defi-shop.com/product/vsd/vsd_top.html ---- lowside switches * See PowerSwitcher, since FETs are also sufficient. * TPIC6A259 is ideal for the small relays and LEDs on v3.x, but not the best choice for HUD matrix lowside (TPIC8101 costs more than 74HC259 /or other latch/ and ULQ2003 together and TPIC8101 delivery is also slow; but footprint is acceptable if the TPIC8101 internal latch saves footprint) . Maybe some unipolar stepper driver, like * 1.5 amp 35 volt unipolar stepper translator - driver chip ucn5804 * ULN2003 (actually ULQ2003 for better temprange) darlington array is very nice (specs, footprint, cost, logistics). No internal latch though. * there are PDTC... sot23 digital NPNs (NPN with internal base resistor) * 100 more: http://www.allegromicro.com/ic/motor.asp but apparently none have latches, or maybe * Micrel MIC5800 4-bit parallel latch/driver ? (logistic nightmare ?) ---- highside switches * PNP (darlington) ---- LED gauges and quantity-display There are 2 types: * LEDbar * moving dot Each can be used from 2..24 LEDs. Arranged in circle, crescent or linear (linear doesn't read nearly as efficiently from the corner of one's eyes) Boundary * sharp: one LED is on, the next LED is off * smooth: ** one LED on, than one partially on (PWM), and the next LED off (for LEDbar) ** one LED at x% and the next at 100-x% (for moving dot) * The boundary can artificially be fluctuated a bit (eg. with a unified or gauss distribution random number or sine) Because of the PWM-ing: 1 LED can also be useful in some cases (special case of the many; becomes a simple PWM-ed output - that can drive other loads too, not just LED): <code> struct ledbar_t { uint8_t last_position; // useful to update .259 output fast; FF=uninitialzed (all LEDs must be set) uint8_t position; // output to display struct softpwm_t .... // needed for PWM-ing }struct ledbar_conf_t { uint8_t ledbar_first_channel; // typically addressing P259 uint8_t ledbar_last_channel; // can be merged with the above (3+3bits) if we assume P259 uint8_t ledbar_conf; // type (ledbar/movingdot); boundary-strategy; can be merged with above two as 3+3+2 bits }</code> Input selection something like GenBoard/Manual/DigitalOut, but for the inputs and internal values. ---- Shift Light idea: I've got another idea.I'd like to make an attractive shift light.My plan is 6 Leds.These could flash up in pairs at three given RPM.Look at this pic for example: This has been implemented for long, with the generic (RPM, kPA, CLT based) switches. You can use the P259 outputs, and connect some LEDs in series (also a series resistor). At least 2 LEDs in series to get the described effect. ---- Sources * Try to find OLED displays (organic led) or normal displays from http://www.optrex.com ---- See also |
