LED Refresh rates

george miyagi

I have an 8x8 array with columns hooked up to a Darlington Array to a 595. Everything seems to be working ok. But I am still getting a visible flicker, more like a bluriness.
If I add another 595, and hence add more code, the flicker worsens.

There's nothing wrong with the power of matrix. If I turn on all lights, it's fine. But when i multiplex, then the fuzziness occurs. This seems to tell me it's the refresh rate.

Is the Basic Stamp2 not fast enough, or could the problem lie elsewhere?

clk CON 0
ser CON 1
latch CON 2
x VAR BYTE 
counter VAR BYTE 
rows VAR BYTE 
cols VAR BYTE 
clk2 CON 3
ser2 CON 4
latch2 CON 5
LOW latch
LOW latch2
counter=128
rows = %00011111 'horiz off
Main:
FOR x = 0 TO 8
counter = counter >> 1
IF counter=0 THEN counter=128
rows =255-counter
GOSUB Send_Cmd
NEXT
GOTO Main

Send_Cmd:
SHIFTOUT ser, clk, MSBFIRST, [noparse][[/noparse]rows\8]
PULSOUT latch, 1
RETURN

Paul Baker

Ok first off change "FOR X = 0 TO 8" to "FOR X = 0 TO 7" Ill continue to look for other areas to optimize, I am convinced the algorithm can be sped up further. What variety of BS2 are you using? How is the column being updated or is this a reduced functionality version of your code?

Post Edited (Paul Baker) : 6/17/2005 2:07:11 PM GMT

Jon Williams

The "bluriness" you're experiencing could be ghosting due to how you're updating the display (I'm assuming it's multiplexed).· If you are attempting to multiplex in PBASIC then speed could be part of the problem.·

I think you might be able to optimize your code a bit.· Give this a try:

' {$STAMP BS2}
' {$PBASIC 2.5

Clock·········· PIN···· 0
Dout··········· PIN···· 1
Latch·········· PIN···· 2
Latch2········· PIN···· 3

idx············ VAR···· Nib
counter········ VAR···· Byte
rows··········· VAR···· Byte
cols··········· VAR···· Byte

Setup:
· LOW Latch

Main:
· FOR idx = 7 TO 0
··· counter = 1 << idx
··· rows = ~counter
··· SHIFTOUT Dout, Clock, MSBFIRST, [noparse][[/noparse]rows]
··· PULSOUT Latch, 1
· NEXT
· GOTO Main

I think this will do what your code is presently doing, albiet a bit more elegantly (I'm taking advantage of PBASIC to a greater degree than you are).· Your code seems to indicate that you're going to have another 595.· You don't need a full second set of pins, you can share the Data and Clock lines -- just use a separate Latch line for the second 595.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

Since he is having a problem with flickering, Ive been trying to steer him to updating the active row by pulsing the clock to the row 595 so that the 0 is shifted once (current code doesn't reflect this as of yet) resulting in the row 595 updating in < 1/8th the time. If he were to use the same clock pin for both 595s, he could not do this speed up since both 595s will shift data (corrupting the unlatched data of the row 595). To perform this speed up he would need a dedicated clock pin for each 595, am I correct in my thinking or can you poke a hole or two in it?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Jon Williams

I'd really like to see the circuit ... it's tough to write code "blind" and with little information. You may be right though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

This is the circuit I envision, I realized that its possible to get away with 4 pins and still do the speed up, instead of having dedicated latches, have dedicated clocks. Since the non-shifted 595 still has the output latches and the internal registers in agreement (since no shifting occured) when both 595s are latched the non-shifted 595 would just relatch the same data (output pins do not change).

Jon Williams

I'd be more inclined to daisy-chain the 595s, update them both in one call, and then Latch them simultaneously. This would use just three pins and simplify the code. The issue, then, is refresh speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

Wouldn't that nearly double the execution time per iteration over my suggested circuit? Two daisy-chain 595s would require 16 SHIFTOUT cycles, where my circuit should take the equivalent of 9 SHIFTOUT cycles. I·concure that the operation of 2 595's through daisy-chaining is the simplest and most straightforward method; but since his primary complaint is too slow of an execution time Im trying to think of a method to squeeze every last ounce of processing power out of the BS2. His previous post on this topic indicated that a 16 bit SHIFTOUT per iteration was too slow. He did use 2 8 bit SHIFTOUTS though, and I don't know how much overhead there is on the SHIFTOUT command.

Post Edited (Paul Baker) : 6/17/2005 4:13:20 PM GMT

Jon Williams

If he's multiplexing, then he's going to change the output of the columns bit on every cycle, and update the rows data for that column (which won't always be the same).· Using logic to determine if the column data has changed or not would probably take more time than simply refreshing the data.· I'd do this (and when I get time, I'm going to as I have an idea for a Halloween prop using this technique):

· SHIFTOUT Dout, Clock, MSBFIRST, [noparse][[/noparse]rowData, colData]

Using this, the connections would be: Stamp --> Col595 --> Row595.· I know the the MAX7219 is a bit pricey vis-a-vis the 595, but that would sure make this project a bunch easier and eliminate any speed issues related to the BS2.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Post Edited (Jon Williams (Parallax)) : 6/17/2005 4:23:05 PM GMT

Paul Baker

Ok I think I now know what your getting at, you are concerned with the blur-over effect of updating the row with the previous column data still present, causing the previous row's data to be displayed while the column 595 is being updated. If he used the output enable pin on the column 595, he could supress this erroneous data from being displayed, but I do see one potential downfall of this setup, during column updates (which under my algorithm would be the majority of an iteration) no LEDs would be lit, reducing the duty cycle and increasing the flickering. Whereas your setup would have no "down time". Hmmm Im starting to wonder if a magic bullet doesn't exist after all, or perhaps the daisy-chain setup would allievate the issue after all, since there are no dead periods within each iteration. He hasn't tried the daisy chain method yet that I am aware of.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Forrest

I was looking over the March, 2005 issue of Nuts and Volts magazine and saw an article that may be of interest. The column is titled 'Side Scolling Display' and uses (10) 5x7 LED array's that are all driven serially. Each row of the 5x7 LED array (anode column/cathode row) is connected to 74HC595 (1 per 5x7 array) and each column is connected a single 74HC595 thru (5) NPN transistors. The display is connected to a GameBoy Advance using just a SDA and a SCL line. I found an inexpensive source for the 5x7 LED array's ($.69 each) so I ordered all the part to put one of these together. A picture of the assembled display is shown here www.nutsvolts.com/toc_Pages/mar05toc.htm

Paul Baker

Ok I think I have come up with the optimal circuit (or close enough to stop working on it). I knew there was a way to make most of the row shift register's operation automatic, but the 595 made it too complicated. So I have replaced the row 595 with a 74*164, a shift register that does not have an output latch. Best of all it still only uses 3 pins [noparse]:)[/noparse]. Here is my plain english algorithm for operating the circuit.


Perform initializations such as initial pin states.
Initialize the 164 by clocking in eight 1s (place 1 on Data and pulse Next_Row 8 times)

Main_Loop

Loop 8 times (n){
Serial shift nth·row's data into (column) 595 (Col_Clk is clock pin, Data is data pin)
If first row, set Data low else set Data high.
Pulse Next_Row
}

Repeat Main_Loop

End Algorithm

This circuit takes advantage of the 595's latch to signal when the row shift occurs. Whenever the data in the internal register of the 595 is latched to the outputs, the value on the Data line is shifted into the 164 at the same time. Since the row and column are updated simultaneously, a column is always lit meaning no "dead time". So this circuit exhibits the same benefit as the daisy chain method, but updates the row almost as a side effect.

If SHIFTOUT always leaves the data pin in the same state,·only test·for when Data needs to be the other state (ie if SHIFTOUT leaves Data=0, do: IF n>0 THEN Data=1), this should save a few cycles.


EDIT: You should get the same 74' family for the 164 as the 595 you already have (if you have a 74HC595, get a 74HC164). This will make the propagation delay as close as possible between the 595 and the 164. Propagation delay is the amount of time it takes for an output to reflect a change in input, each 74' family has different delays and you want the outputs of the 164 and 595 to change at the same time as much as possible.

Post Edited (Paul Baker) : 6/17/2005 10:03:27 PM GMT

Jon Williams

Did you actually wire it up and test it? When I get home to Dallas I will connect two 595s (daisy-chained with common latch) and give that circuit a go.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

No I dont have a 595 on hand or a matrix (or even 64 discrete LEDs). I did however "hand test" it by drawing out logic and timing diagrams of its operation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

george miyagi

Thanks. I quickly tested John's code and there was definitely a reduction in flicker, though still not perfect - lights are still a bit blurry. And will get back later with the other results, once I have digested and tried out all the things mentioned. Thank you!!!

The schematic I'm using is the one from StampWorks3 modified slightly

The reason I'm not using the 7219s is that I need to build 5 screens of 32x16, meaning I would need 40!!!! Along with 5 basic stamps and all the LEDs etc. this is some serious outlay for my exhibition...

Anyway, I'll try do some shopping today and see if I can get my hands on a couple of 164s and try that method out too.

<addendum - John's code works fine when the whole matrix is to be lit, but I seem to run into the same problem when addressing individual lights>

Post Edited (george miyagi) : 6/18/2005 11:31:11 AM GMT

Jon Williams

I don't think you're going to pull it off using shift registers -- the process of getting data to them is just too slow. You might consider using an SX chip to multiplex your LEDs like we did with the Robo-Olympics badge we made. I made an LED multiplexer in SX/B that the BASIC Stamp can talk to (essentially, it's just a serial version of the 7219 but built with an SX). Now that SX/B supports the SX48 and SX52 you have plenty of pins available.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

george miyagi

thanks john
that's what i feared.

so your advice:
using BS2: if i use the 7219 would this have enough speed for what i'm trying to do, taking into a/c that i need to build a matrix of 32x16
using the SX: would this work with the 595s, or would I still have to use 7219s.
After having forked out ¥20 000 (yes, your products are super-expensive in Japan), I need to do some serious research and thinking about this project. - though i'm sure i'll find a use for the BS2, and have learnt a lot from it, and it's nice to know i wasn't going crazy this last week.

Anyway, i digress. I'm on major time constraints to get this working. So do you suggest i go the SX way or 7219 way. The reason i went with the 595 were they were much easier to get my hands on and of course their price as compared to the 7219s.

thanks again for everybody's amazing help so far
regards
george

Jon Williams

George,

If you're looking to create a dynamic display then I would suggest the SX route -- you can (using my other project as a guide) create a custom display controller using an SX48.· Does your 32x16 display mean 32 rows or 32 columns?· If it's 32 columns, then you could use a couple 74x154 decoders and five I/O lines to select the column for display, then use two ports for the 16 row LEDs that would be lit.· SX/B on the SX48/52 allows large arrays, so you could create a 64 byte array that is the display buffer.· The "foreground" code would simply select a column, then put the LED data onto the LEDs.

Now, none of this is particularly easy, but it can be done.· Desho?

Gomen nasai about the high prices in or Parallax products Japan (it happens in Europe, too)·... exporting goods between countries always seems to benefit the tax and tarrif collecting agencies on both sides.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

KenM

George,

Where are you in Japan? I usually travel to Japan at least twice a year. I might be able to pick up some product for you here locally and deliver it to you in·Japan at U.S. prices.　(Without being thrown in jail?)

よろしですか

もし　ほしい　です　プラーベト　エメル　下さい

ケン

·P.S. Upon closer reading of your post I noticed you need the parts soon, but I will not be in Japan until the fall.


Post Edited (KenM) : 6/18/2005 4:21:15 PM GMT

george miyagi

Thanks guys.
i'm gonna try out the 7219 route and see where that gets me. SX is no go for me as I'm on a Mac.
and thanks Ken for the offer, though time is against me at the moment.
regards
g