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.

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.

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.

Okay, it's been a pretty bad year. It turns out the Maestro application wizard won't do code that would actually compile with MPLab IDE, and googling on the problem I found a similar issue posted on Microchip forum, post dated 2005, with no help or replies. So no LED testing yet. There is a wide variety of LEDs with different brightness available though, so it wont' be a problem.

Anyway, I've been doing some considerable rethinking on the system. Allegro discontinued their 32-bit LED drivers, but offer newer 16-bit drivers with some very nice features, and Maxim offers really nice serial drivers as well.

The timer I made for the ASCII display turned out to be a vain effort; upon closer reading of the datasheet, it plainly stated out; "Designers not wishing to use Read function may tie pins !CE and !WR together". So that's a big bonus. Also, I could emit both pins A3 and D7 (they are only needed for user defined characters), further helping with the wiring.

Going with sink driver only meant reversing the LEDs on the display boards and changing the displays to Common Anode style (though, matching common anode 3x7 and 4x7-segments are much more difficult to find than common cathode for some reason).

Anyway, here's the revised display board schematic:

Reconfigurable pins have been reduced to minimum. The original setup was wholly unnecessary and createed an impenetrable mesh of wired on the board. This is simple, nice and offers good forward compatibility with possible future revisions.

Here's how it worked out as PCB:

.

The thick traces are common anodes for the LED arcs. Going by the number of LEDs and their highest allowed overdrive setting, the highest current they will see is 4 A, but only at about 2% duty cycle (if even that) and only when the leds are driven at full brightness at maximum display value. Any case, LEDs will burn out LONG before the traces. However, running 103 leds per board can cause a bit of heating, I tried to arrange the wires so it'd be as even as possible.

The PCB mask image shows the LED arc traces best, so here's a shot:

I personally like how the common anode traces turned out, the one running between pads is a bit thin but I can hardly imagine it causing trouble. The only thing I do worry is the two anodes running directly on top of each other at the outer edge.

I've tried to minimize the number of vias on the board, as there's already more than enough holes on it.

There's a 3D package for Eagle, but since it uses POVRay which is a write-only format and one of the worst examples of complacent circle jerk software available, I really have little need or interest to bother with it.

Hi, I've just discovered your project. Great work there by the way. I've been working on a similar project myself, using a PIC 18f4680, a digital dashboard which is very similar in appearance to the display using in the 1984-1987 Audi Quattro...

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum