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.

What is the best way to communicate between two PICs to drive multiple LCDs

Fluffyboii

Active Member
In this post you can see me struggle with driving Static drive LCDs with MUX mode. MUX drive mode creates segments that partially lit up when they should be off. So my only option is direct driving the 7 segment LCDs. PIC16F1939 can only drive 24 segments on Static mode. Which means it can only drive 3 digits. I was thinking of possible ways to tackle this problem but the cheapest and easiest way to do this seems to be using a PIC16F1936 as a slave to drive 2 digits itself and driving other 2 digits with the PIC16F1939 or just using two PIC16F1936s. Since I already have a PIC16F1936 and 1939 in SMD package first option is fine by me. I can design a simple PCB to solder the LCDs and microcontrollers on.

I know it is extremely wastefull in terms of processing power to use another MCU to drive 2 digits woth of LCD displays to make a dumb clock but this is possibly the cheapest and easiest option since I already have the PICs and I do not want to buy another PIC or PICkit.

So what is the most optimal way to comminucate between the MCUs? Should I look into Serial communication or I2C? Or should I just use digital pins to send binary data directly to the second PIC? Since the only purpose of the second PIC will be displaying numbers and maybe letters it should not need a fancy communication protocol and 5 digital pins should be enough to send whatever I want displayed in binary. Could possibly use the DAC and ADC in these PICs to send analog voltages that equal to whatever I want displayed I guess but sounds like a big hassle to program. The use of two MCUs to drive LCDs is probably a unnecessary bid hassle anyway, I guess.

Since the whole project of making a dumb clock got out of hand in terms of costs and efford involved I am okay with wasting even more resources and time into it. If I can use the second slave PIC for something else than just driving the LCDs, for example getting button inputs etc. I will be able to justify using two microcontrollers. The whole thing is a solution looking for a problem to solve.
 
Hi F,
Try not to think of it as wasting time! I've been on the same project for 6 years! I mix the ambition of finishing the project with learning, and today I've learnt something that make a 'thing' work, so I've used up some time, but that's fine.

I use both UARTS and SPI. For my purposes I chose SPI ove I2C and now it's working fine. There are ways of visualising the data as it moves, and it's not too expensive (digital analyser)
C.
 
Hi F,
Try not to think of it as wasting time! I've been on the same project for 6 years! I mix the ambition of finishing the project with learning, and today I've learnt something that make a 'thing' work, so I've used up some time, but that's fine.

I use both UARTS and SPI. For my purposes I chose SPI ove I2C and now it's working fine. There are ways of visualising the data as it moves, and it's not too expensive (digital analyser)
C.
6 years is quite the dedication. I have a tendency to overdo things and burn myself out. I am making a real cool clock at the moment though, will post it when its done. I will use the LCDs later :)
 
6 years is quite the dedication. I have a tendency to overdo things and burn myself out. I am making a real cool clock at the moment though, will post it when its done. I will use the LCDs later :)
Hi F,
Yes, it sound like it is, but some people do crosswords every day, then throw them away, where my project is better than it was when I started :)
Looking forward to see your clock.C
 
Last edited:
Ghost segments are usually caused by changing the segment values with the common still selected. Ensure you switch of the common anode/cathode output before changing the segment. Ghosting is always fixable.

Better to correct your problem rather than introduce another pic and possible communication problems.

Mike.
 
Ghost segments are usually caused by changing the segment values with the common still selected.

For background, he's using the dedicated LCD drive system in a PIC, but with individual large digit displays rather than a multi-digit display.

There are not enough pins on a single device to drive every LCD pin separately, and if the digit commons are connected together it causes the ghost segments.
 
For background, he's using the dedicated LCD drive system in a PIC, but with individual large digit displays rather than a multi-digit display.

There are not enough pins on a single device to drive every LCD pin separately, and if the digit commons are connected together it causes the ghost segments.
Ghost segments are usually caused by changing the segment values with the common still selected. Ensure you switch of the common anode/cathode output before changing the segment. Ghosting is always fixable.

Better to correct your problem rather than introduce another pic and possible communication problems.

Mike.
Just to add some of my findings about LCDs here: Regular multiplexed displays have a limited viewing angle before unlit and lit segments become indistinguishable. Direct drive displays do not posses this issue unless I multiplex them. When I multiplex them they get some amount of ghosting, similar to the multiplexed LCDs. I think it is not possible to get rid of it since I have not much control over the PIC's LCD driver.
 
Last edited:
Have used this module , 6 large digits has an serial interface green backlight.
lcd6.jpg
 
Back
Top