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.

^ This man speaks the truth! In industry they use it to lower the cost rather than increase the quality and call it "agile development".

The overdrive issue JUST got a twist...


FFFFFFFFFFFFFFF
FFFFFFFFFFFFFFF
FFFFFFFFFFFFFFF
FUUUUUUUUUUU
UUUUUUUUUUUU
UUUUUUUUUUUU
UUUUUUUU

The source driver I need is an A6818 chip, NOT A6832. Got those mixed up (6832 is a sink driver). The good thing is A6818 is much faster than 6832, the bad thing is the 6818 can only manage 40mA. It is intended, among other things, as a LED driver, and the 10MHz is a "guaranteed" minimum operating frequency, norm being 33MHz. I think it should be possible to keep the leds on for a much longer time now, which is good. Also the poor ribbon cable isn't beaten over it's limits so much by this way. The only big question is will it be bright enough with the inherently very low duty cycle.

Don't worry about me rushing into making a prototype, not just for wasted hours, but the bill for the parts at retail prices is something you should read only while firmly seated... Spider senses tell me Santa is going to bring me a breadboard this christmas

Alas, I don't think it's possible to strobe in only the visual data, as the display addressing works in this manner:


Before the voltage is fed to the LEDs, the proper segment is addressed first by sending in a short address data pulse with an address latch signal; the latched signal then sets the FET at the addressed LED display element conductive. Then the visual data is loaded onto the bus.

man, this is a lot of work .. have you seen the maxim parts yet which do a lot of this muxing/driving stuff for relatively free ?
look here <- just the beginning, browse the automotive section too.
just hang them off of a serial bus (i2c/spi) and tell it what to do while you go off and collect data to throw up in your displays.

lots of free samples to at least experiment with on your new devboard

Now that looks interesting Maxim sure has a nice range of display chips.

I actually had an idea on how to cheat bigtime from doing binary -> 7-segment decodes in the actual code; just send the data into a decoder chip and read back with a parallel-to-serial shift register and SPI. Then call it "hardware acceleration" because it sounds way cooler than "I'm much too lazy to bother to learn to code this stuff" Then again, I don't see why not really, it DOES save quite from bit of coding, and if anything, I've got SPI channels to spare.

Alright, I ordered some parts I'll need for testing... Namely, a PIC18f4580 µC, A6832 sink driver with a PLCC pin socket and a bunch of specified LEDs. The rest comes after I've seen if the setup is viable.

You'll notice I ordered a 6832 and not the 6818 source driver; I figured that a sink driver could in fact be better option, since common anode display units are less common than common cathode, and there's more current. This way I also could use 12v for the LEDs if I *really* need to crank them up. Also I think there is less chance of unexpected behaviour, since the segment power FETs are now at the source and not between the load and PWM earth. The worrying bit is I heard the 6832 is soon to be phased out.

subscribed!