Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

2-Digit LCD or LED Display Problem

Status
Not open for further replies.

GizmoWizard

Member
I’ve put together a prototype speedometer using a GPS module and PIC microcontroller. It would be used to replace the non-functional speedometer in my old car, for small vehicles that don’t already have one, etc. My prototype circuit works great but I’ve run into a problem in displaying the speed on a readout large enough to be seen from the driver’s vantage point. These are the only choices I know of:

LCD – This would be my first choice since my prototype is already driving a two-line character LCD, and it would use less parts and power. But I haven’t been able to find a character LCD with a large enough font size (character height).

LED – I’ve found a two-digit multiplexed LED module with 0.6” character height that would just barely be satisfactory. The PIC could directly run an LED display but couldn’t drive the 7-segment digits with enough current to be bright enough. Plus the continuous process would take up a lot of processing time away from the PIC’s other duties.

I could have the PIC drive two MC4511 BCD-to-7-segment latching chips but their outputs are not multiplexed, so that would require running 14 lines from the extra two ICs to two non-multiplexed digits; a significant pcb layout challenge.

Any other ideas? Can anyone help me with this please?

Gizmo
 
Use discrect LEDs in a numric pattern. Charlypex them with ULN type drivers. Andy
 
Sorry its "charlieplexing" running lots of LEDs off a few PIC pins. Andy
 
Charlieplexing will reduce the max brightness. If you want even more brightness use high output LEDs and PWM them to get the desired brightness.

The old school way would work if you have time.

Use parallel LED strings withe one current limit resistor per string to create each segment of a 7 segment display. Drive each segment with a transistor.

Create a mask and defuser.
 
I thank you all for your suggestions.

I don’t think that I need to build my own displays. Larger, brighter single-digit LED displays are already available if the requirement for multiplexing is removed. But I’d still be stuck with the same problems in the “LED” option described in my first post.

An IC (or circuit) something like an MC4511 with BCD inputs and latches but that has multiplexed outputs too would be great, if one exists. The ideal readout though would be a single- or double-line character LCD with at least a .6" character height.
 
You do not need any additional logic.

Control each segment of the 7 seg displays with a PIC pin.

If you need more then the PIC can drive use a transistor.

Yes 3v0, you’re right. I had initially figured that was the method I would use, and if necessary, add a transistor array to the segment lines. Then continuously switch the two digits (for multiplexing) via an interrupt in the microcontroller.

But the MCU is very busy: sifting through the data coming in from the GPS module (via its USART) looking for the knots data, doing string/integer conversions, the math to get MPH, passing the MPH value to the LCD’s driver, then repeating the whole procedure. New data only comes in once per second, so it’s all somewhat time dependent to keep the speedometer readout as current as possible.

The ability to just hand the data over to a driver and then continue on, without having to continuously control its display, makes for a rather smooth C program flow. I could be wrong, the MCU might be able to handle all of this (you would know better than I). But I cringe a little at the thought of going back and writing a lot more code just to prove it.

Does any of this make sense, or am I just overly paranoid?
 
Perhaps your paranoia has some reason behind it. Using 7 pins on the pic for 2 segments, you would need to multiplex them. This means updating each 7 segment atleast every 1/24s. You could do the math based on the processor speed and how many characters are being sent at what baud rate and figure out how much time all that would take.

Worse comes to worse, run a timer to cause an interrupt to update the 7 segments, you can think of this as multitasking.
 
I know it is common to multiplex 7 seg displays to save pins. So much so that no one seems to have read correctly what I wrote. Let me try again.

14 pins can control 2 7 seg display without multiplexing! If you do not have 14 extra pins shift the data out to a 74HC595. (3 pins)

Either way you turn on the needed segments and you are done. No multiplexing, no interrupts. And better yet full brightness.
 
Oh!, now I get it! Sorry 3v0, like you said, I assumed you were talking about multiplexing the 7-seg digits. Your method opens up a lot of possibilities that I hadn't even thought of until I read your reply. Also makes for some simple coding. Thank you very much.
 
I am using the version with the CA 4 digit and the TPIC6C595 high current driver coupled with a hi eff. Lumex display that delivers 13mcd at 10mA per segment. I am using 100ohm resistors to deliver about 30mA per segment at full brightness multiplexed
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top