Re: My Digidash project
Posted: Thu Dec 10, 2009 8:02 pm
How about doing an experiment to start with ..
verify what 160ma (or 125ma actually) @ 10% looks like. There's a whole cascade of other things in the hardware you can verify @ the same time by doing this... for ex:
1) as configured, can the hardware acurately drive at that strength ?
2) is the info that the mfg gave you correct ? (i've been burned a number of times by this)
3) how do other users 'see' the display .. is it too bright/low/'flickery',etc ...
4) along w/#2 - is the lifetime effected ?
5) does #3 change w/age ?
6) how efficient is your firmware architecture for acheiving the above ? does it scale cleanly to support the other planned features ?
.. by figuring out a few of the above (which appears to be the center of your masterpiece) you'll know if you're going down the right path. If you need to change gears, it won't be so painful and you don't have a useless one off proto that you've invested a lot of time in ... in short, iterate on a smaller scale and then integrate, I think you'll get from start to finish much faster with something much more robust.
.. and one more thing to think about ... not sure if I missed this one .. your writeups are excellent and very dense:
why not just constantly shift in the latest data and use your timer isr to simply modulate the drivers 'BLNK' pin ? in fact, you could just use the internal timer to throw out a pwm sig to the BLNK pin. It looks like you might have to change around your h/w config to support that.
with sourceboost, you'd also get some stack warnings if it determines (through static analaysis) that you might overflow it.
verify what 160ma (or 125ma actually) @ 10% looks like. There's a whole cascade of other things in the hardware you can verify @ the same time by doing this... for ex:
1) as configured, can the hardware acurately drive at that strength ?
2) is the info that the mfg gave you correct ? (i've been burned a number of times by this)
3) how do other users 'see' the display .. is it too bright/low/'flickery',etc ...
4) along w/#2 - is the lifetime effected ?
5) does #3 change w/age ?
6) how efficient is your firmware architecture for acheiving the above ? does it scale cleanly to support the other planned features ?
.. by figuring out a few of the above (which appears to be the center of your masterpiece) you'll know if you're going down the right path. If you need to change gears, it won't be so painful and you don't have a useless one off proto that you've invested a lot of time in ... in short, iterate on a smaller scale and then integrate, I think you'll get from start to finish much faster with something much more robust.
.. and one more thing to think about ... not sure if I missed this one .. your writeups are excellent and very dense:
why not just constantly shift in the latest data and use your timer isr to simply modulate the drivers 'BLNK' pin ? in fact, you could just use the internal timer to throw out a pwm sig to the BLNK pin. It looks like you might have to change around your h/w config to support that.
with sourceboost, you'd also get some stack warnings if it determines (through static analaysis) that you might overflow it.