Daisy-chaining max7219s
Archiver
Posts: 46,084
Hi,
I've got six Max7219s daisy-chained as shown in the application notes. It
almost works (the almost part is driving me crazy!). Each is driving an 8x8
LED matrix that are all butted up together to form a 32x16 matrix. This is
for low-res video. The way its supposed to work is that the display data
from my desktop is received by a BS2sx using the Serin command. Shiftout is
then used to light up the given row of each matrix.
The problem is that after anywhere from a few seconds to few minutes the
individual matrices start blanking out, no longer displaying their data or
illuminating at all, until I reset. This happens in no particular order. I'm
usually left with one or two that continue to function correctly.
Additionally, sometimes the Stamp starts freaking out, resetting itself,
gibberish in the debug window. If this happens I have to shut off the power.
This is what I've learned. The screen works reliably when the stamp shifts
out a self-generated pattern to the screen. It even works reliably when the
stamp is additionally receiving data via Serin (the data debugs correctly).
It stops working when the Serin variables are passed to the Shiftout
variables (see the code below for more info).
A few other details: I know the baud rate is fast (57.6 kb/s), but as I said
the data debugs correctly and nothing changes when I lower it. Also I am
using a computer power supply which is regulated and provides ample power to
the circuit. The only other thing which affects the display is the capacitor
placed across the power lines. The screen doesn't work at all without a cap
(even though no cap is listed in the app notes). And the size of the cap
seems to affect on duration (I've tried everything 0.01uf to 1000uf), though
none solves the problem.
This is hard to explain, but hopefully someone out there knows what I'm
talking about and knows the solution.
TIA
Nick
'Here's the main routine
Main:
Serout OUTpin,16407,[noparse][[/noparse]0] 'request next video frame
For row = 1 to 8 'for each row of LEDs in a matrix
Serin INpin, 16407, [noparse][[/noparse]x0,x1,x2,x3,x4,x5] 'receive a pattern for each matrix
Shiftout DATA,CLK,MSBFIRST[noparse][[/noparse]row,x0,row,x1,row,x2,row,x3,row,x4,row,x5]
Pulsout LOAD,1 'illuminate the row in the pattern
Next
Goto Main
I've got six Max7219s daisy-chained as shown in the application notes. It
almost works (the almost part is driving me crazy!). Each is driving an 8x8
LED matrix that are all butted up together to form a 32x16 matrix. This is
for low-res video. The way its supposed to work is that the display data
from my desktop is received by a BS2sx using the Serin command. Shiftout is
then used to light up the given row of each matrix.
The problem is that after anywhere from a few seconds to few minutes the
individual matrices start blanking out, no longer displaying their data or
illuminating at all, until I reset. This happens in no particular order. I'm
usually left with one or two that continue to function correctly.
Additionally, sometimes the Stamp starts freaking out, resetting itself,
gibberish in the debug window. If this happens I have to shut off the power.
This is what I've learned. The screen works reliably when the stamp shifts
out a self-generated pattern to the screen. It even works reliably when the
stamp is additionally receiving data via Serin (the data debugs correctly).
It stops working when the Serin variables are passed to the Shiftout
variables (see the code below for more info).
A few other details: I know the baud rate is fast (57.6 kb/s), but as I said
the data debugs correctly and nothing changes when I lower it. Also I am
using a computer power supply which is regulated and provides ample power to
the circuit. The only other thing which affects the display is the capacitor
placed across the power lines. The screen doesn't work at all without a cap
(even though no cap is listed in the app notes). And the size of the cap
seems to affect on duration (I've tried everything 0.01uf to 1000uf), though
none solves the problem.
This is hard to explain, but hopefully someone out there knows what I'm
talking about and knows the solution.
TIA
Nick
'Here's the main routine
Main:
Serout OUTpin,16407,[noparse][[/noparse]0] 'request next video frame
For row = 1 to 8 'for each row of LEDs in a matrix
Serin INpin, 16407, [noparse][[/noparse]x0,x1,x2,x3,x4,x5] 'receive a pattern for each matrix
Shiftout DATA,CLK,MSBFIRST[noparse][[/noparse]row,x0,row,x1,row,x2,row,x3,row,x4,row,x5]
Pulsout LOAD,1 'illuminate the row in the pattern
Next
Goto Main
Comments
It sounds like your power supply is insufficient, or your regulator is
shutting down from thermal overload. Make sure you have a regulator
that can handle the load requirements to avoid resetting the Stamp
when shifting data out to light the displays.
Regards,
-Bruce
tech@r...
http://www.rentron.com
Original Message
From: "Nick Stedman" <nickstedman@s...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, September 19, 2002 9:19 AM
Subject: [noparse][[/noparse]basicstamps] Daisy-chaining max7219s
> Hi,
> I've got six Max7219s daisy-chained as shown in the application notes. It
> almost works (the almost part is driving me crazy!). Each is driving an 8x8
> LED matrix that are all butted up together to form a 32x16 matrix. This is
> for low-res video. The way its supposed to work is that the display data
> from my desktop is received by a BS2sx using the Serin command. Shiftout is
> then used to light up the given row of each matrix.
>
> The problem is that after anywhere from a few seconds to few minutes the
> individual matrices start blanking out, no longer displaying their data or
> illuminating at all, until I reset. This happens in no particular order. I'm
> usually left with one or two that continue to function correctly.
> Additionally, sometimes the Stamp starts freaking out, resetting itself,
> gibberish in the debug window. If this happens I have to shut off the power.
>
> This is what I've learned. The screen works reliably when the stamp shifts
> out a self-generated pattern to the screen. It even works reliably when the
> stamp is additionally receiving data via Serin (the data debugs correctly).
> It stops working when the Serin variables are passed to the Shiftout
> variables (see the code below for more info).
>
> A few other details: I know the baud rate is fast (57.6 kb/s), but as I said
> the data debugs correctly and nothing changes when I lower it. Also I am
> using a computer power supply which is regulated and provides ample power to
> the circuit. The only other thing which affects the display is the capacitor
> placed across the power lines. The screen doesn't work at all without a cap
> (even though no cap is listed in the app notes). And the size of the cap
> seems to affect on duration (I've tried everything 0.01uf to 1000uf), though
> none solves the problem.
>
> This is hard to explain, but hopefully someone out there knows what I'm
> talking about and knows the solution.
>
> TIA
> Nick
>
> 'Here's the main routine
>
> Main:
> Serout OUTpin,16407,[noparse][[/noparse]0] 'request next video frame
> For row = 1 to 8 'for each row of LEDs in a matrix
> Serin INpin, 16407, [noparse][[/noparse]x0,x1,x2,x3,x4,x5] 'receive a pattern for each matrix
> Shiftout DATA,CLK,MSBFIRST[noparse][[/noparse]row,x0,row,x1,row,x2,row,x3,row,x4,row,x5]
> Pulsout LOAD,1 'illuminate the row in the pattern
> Next
> Goto Main
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and Body
of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
once the power supply drops out of regulation and the Stamp resets. Run the
stamp off a separate battery (don't forget to tie the grounds together) and
see what gives.
If you have a DVM with a min/max feature you can use it to monitor your
power supply voltage -- it should catch even short-duration voltage sags.
Original Message
> It sounds like your power supply is insufficient, or your regulator is
> shutting down from thermal overload. Make sure you have a regulator
> that can handle the load requirements to avoid resetting the Stamp
> when shifting data out to light the displays.
> > I've got six Max7219s daisy-chained as shown in the application notes.
It
> > almost works (the almost part is driving me crazy!). Each is driving an
8x8
> > LED matrix that are all butted up together to form a 32x16 matrix. This
is
> > for low-res video. The way its supposed to work is that the display data
> > from my desktop is received by a BS2sx using the Serin command. Shiftout
is
> > then used to light up the given row of each matrix.
> >
> > The problem is that after anywhere from a few seconds to few minutes the
> > individual matrices start blanking out, no longer displaying their data
or
> > illuminating at all, until I reset. This happens in no particular order.
I'm
> > usually left with one or two that continue to function correctly.
> > Additionally, sometimes the Stamp starts freaking out, resetting itself,
> > gibberish in the debug window. If this happens I have to shut off the
power.
> >
> > This is what I've learned. The screen works reliably when the stamp
shifts
> > out a self-generated pattern to the screen. It even works reliably when
the
> > stamp is additionally receiving data via Serin (the data debugs
correctly).
> > It stops working when the Serin variables are passed to the Shiftout
> > variables (see the code below for more info).
> >
> > A few other details: I know the baud rate is fast (57.6 kb/s), but as I
said
> > the data debugs correctly and nothing changes when I lower it. Also I am
> > using a computer power supply which is regulated and provides ample
power to
> > the circuit. The only other thing which affects the display is the
capacitor
> > placed across the power lines. The screen doesn't work at all without a
cap
> > (even though no cap is listed in the app notes). And the size of the cap
> > seems to affect on duration (I've tried everything 0.01uf to 1000uf),
though
> > none solves the problem.
> >
> > This is hard to explain, but hopefully someone out there knows what I'm
> > talking about and knows the solution.