My Digidash project

Non-EMS Electronics related discussions and projects in here please.
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: My Digidash project

Post by EssEss »

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.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: My Digidash project

Post by Fred »

EssEss wrote: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.
^ This man speaks the truth! In industry they use it to lower the cost rather than increase the quality and call it "agile development".
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: My Digidash project

Post by KW1252 »

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:

Image
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.
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: My Digidash project

Post by EssEss »

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 :)
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: My Digidash project

Post by KW1252 »

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" :lol2: 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.
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: My Digidash project

Post by KW1252 »

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.
george graves
TO220 - Visibile
Posts: 12
Joined: Sun Apr 20, 2008 9:32 am

Re: My Digidash project

Post by george graves »

subscribed!
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: My Digidash project

Post by KW1252 »

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:
Image

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:

Image.

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:

Image

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.
coupequattro
TO92 - Vaguely active
Posts: 1
Joined: Sun Jun 24, 2012 11:54 am

Re: My Digidash project

Post by coupequattro »

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...

Very like this in fact

http://rolf-koehler.com/privat/Hobby/Ur ... hj~005.jpg

The original dash had a stepper motor driven mechanical odometer, which I changed to solid state. My project uses LED's for display, the original dash used VFD technology.

The dash is working, and has been run in the car. However, I have a little bit more work to do on the code to finish off...

I'll round up some photos for you all in the next few days :)
Post Reply