5x7 Led Dot Matrix Flickering Problem

[veerabahu]

Hi Experts

I am developing code for 5(Column)x7(row) Led dot matrix display,I am using 18f4520 IC. My aim is to receive the 16 characters through UART and display it in 16 digits, 5(Column)x7(row) Led Dot matrix. As a first step of this project i developed the code for displaying the fixed character like "A,B,C,D,E,F,G,H" in first 8 digit 5x7 led dot matrix. So for 8 characters i want to control 40 columns via shift register (74hc595). The rows are connected with B port IO's.
At first I tried to execute the code with 10MHZ Clock speed. I got the output but i faced the flickering problem. To avoid the flickering problem I reduced the delays in between the each LED'S switching. Result, I got flickering arrested but brightness decreased.
So I planned to increase the clock speed to 40 MHz with the help of configuration H4 in fuses. But i didnt see any change in the speed of the crystal. I didn't see any change in the Display.

Please help me to solve this problem. I attached my code below.

[temtronic]

re: LED brightness

How bright an LED looks is based on two things, 1) time it is on and 2) current it draws.

When you increased the 'loop ' speed to get rid of the flickering, you reduced the time an LED was on...so it got dimmer. The easy way yo compensate for that is to incease the LED current BUT be careful too much current for too much time WILL burn out the LED.
There's actually a fair amount of 'math' you can do to get it to work or just reduce the LED resistors by say 50%. Try that,if not enough, reduce by another 50%. Just be careful.

On a lot of 'multiplexed' displays ( which is what you've made), the mfr allows 10* the normal current for the LEDs. The problem is that if the 'multiplexing' stops, the LEDs will burn out.

Jay

[Mike Walne]

I believe you should have loads of time to handle this with 10MHz clock.
That's working at 2.5 MIPs, or 0.4us per machine cycle.

You need to completely update the display at say 100Hz ie once every 10ms.
Each update requires you to active each of your 8 rows in turn.
That's 1.25ms per row.

So the sequence goes like this:-


1) Turn off all rows. (ie portB drives)
2) Send data to row0. (ie data for the 40 LEDs in row0)
_3) Latch row data.
_4) Activate appropriate row. ( ie row0 at start)
_5) Send data for next row.
_6) Delay.
_7) Turn off all rows.
_8) Loop round to 3.


The biggest time consumer is element 5.
You're sending 40 data bits.
Should take ~10 machine cycles each.
So total for element 5 is 40*4us = 160us.
Leaves about 1ms for delay in element 6.

Mike
EDIT

Jay and I are assuming you do have current limiting resistors.
That's 40 off, ie 1 in each lead, from the matrix to the '595.
And NOT 8 off in the port B connections.

Power considerations also suggest you may need to buffer port B.

Do the maths.
Start from an assumed average current for a reasonably bright LED, say 1mA.
Multiply by 8 for the multiplexing to get your resistor value, now 8mA.
Each '595 port handles this 8mA, should be OK
Multiply by a further 40 for the case where ALL the LEDs in a row are ON, now 320mA.
That current will probably destroy your PIC, hence the buffer.
Check with the PIC data sheet.
You don't tell us which way round your matrix is arranged, so can't help further.

[Ttelmah]

The big improvement would be to use the compiler SPI routines, or even better the SPI hardware. Currently the bytes are being clocked out using a software loop. This could be done probably 3* as fast by the compiler routines and perhaps 30* as fast using the hardware.....

[Mike Walne]

In your original post you say you want to drive 16 digits. That's 80 columns.
So your drive requirement per column stays the same but per row is doubled.
It's a simple fact of life for mux displays, one of either row or column drivers have to be able to drive the entire display.
Also bear in mind your display power supply has to be able to handle current which varies rapidly from ~zero to the maximum of (average LED current ) * ( No of LEDs).

With only half your display assembled you can get a feel for the intended whole display by running code as though all 16 digits were there.
(Simply send dummy data to the missing digits.)

As soon as you get your code to do other tasks you will get weird modulations in the display.
To make the display stable you need to accurately control the time each row is lit.
The easiest way is to use a timer interrupt.

The interrupt routine:-
a) Turns off all the row drivers.
b) Latches new data into the '595s.
c) Turns on the next row driver.
d) Sets an display_update_flag to tell main to prepare and send the next row data bits.
(It's important to turn ALL the LEDs off whilst the display updates to prevent ghosting.)

Main polls the display_updated_flag and does the rest.
Using either the CCS supplied '595 driver or the hardware SPI will seriously reduce your software overhead.

Mike