LED matrix display driving techniques

[neazoi]

All the techniques I have seen in driving a LED matrix display refer to scan each row and set a bit in this row each time. Then go to the next row and set the next bit, then to the next row etc. By row cycling very fast the user sees all the set bits of the screen simultaneously, despite they are set one at a time. Obviously this is done for hardware minimising but this is depended on the speed of the logic involved.

I have thought of using flip flop buffers, one for each row and column to "keep" the state of the set bits in each column and row. This means that each time the microcontroller that drives the display just needs to refresh accordingly only specified bits and not the whole screen, by just setting accordingly its pins. But this also means that because of the "memory" (flip flops) each bit has to be cleared manually if it needs to switch off. This has the advantage that no complex timing needs to be kept and there could be other advantages I cannot think of now.

Do you think this second approach could be feasible or useful at all?

 

[thannara123]

Tell me more about it

 

[hexreader]

74HCT595 kind-of does much of what you suggest, cheaply, and is a common approach.

There are dedicated LED driver chips that are more expensive, but do more of the work for you.

What you suggest seems to me to be adding complexity to save complexity. No obvious gain.

If "simple to program" is what you want, why not have one dedicated MCU handle the multiplexing and timing for the LEDs and have a second MCU send it data for display over serial link (I would use UART).

Worked for me.....

 

[neazoi]

The reason for not doing this is basically programming skills. It seems to me easier to just set a few bits each time to activate or deactivate the relevant bits on the screen than trying to compose the serial data stream. When the screen is on the wait state, ie when there is no change to be displayed, then the mcu could do something else and not bothering about the screen refreshing. All you need to know in order to display something on a row, is the relevant combination of binary number to send to the screen row. This number will be demultiplexed and then correspond to that row. at the same time you send the relevant combination number to the column.

Other reasons that one might think to do it this way may include is expandability. If you expand your led screen to much more rows/columns, there will be a case where the hardware speed (mcu/logic/leds) may be the limiting factor. If the row scanning rate is too high, in order to keep for the difference, this may cause the leds to get dim and not display at all at some time.

Another reason may be power consumption possibly. I am not sure if the power that a micro consumes depends of the amount of work it does, but since it includes a cpu, it may be the case. The screen "buffers" although, will probably consume more power this way anyway.

If you use the row-scanning method you always need a micro to do the job. If you use the method I propose you may be able to drive the screen with simpler electronics (just a though) since there is no serial data stream and complex timing to cope with. You can "refresh" the screen at any time interval you wish and do this for just specific bits.

It sure adds more components to the circuit but at the benefit of simpler programming and easier interfacing.

What do you think of this?

 

[hexreader]

What do you think of this?

If you enjoy building the hardware and can cope with the extra hardware complexity, then go for it.

It sounds feasible to me, and once it is built, you can be proud of the accomplishment.

I do not think the result would be a viable commercial product, but as a one-off fun project, it sounds cool.

This project sounds interesting, please keep the forum updated with your progress in this thread.

 

[ZASto]

@neazoi: I think that the mentioned HC595 are the way you should go. You simply shift the data through the 595's and latch the data in it's output buffer, after thatyour micro could performe other tasks as the 595's are at that moment fully static. Chip count: NoOfLEDs / 8.