Loss of synchronisation: Are the chips reliable?

A lot of you are familiar with the method of using a shift register to
multiplex a matrix of LED's.

My college project this year was to make a Connect4 game consisting of
a 7x6 matrix of LED's.

I had two choices for implementing the display:
   1) Use two pins from the microcontroller
   2) Use one pin from the microcontroller

The technique of using two pins would be something like as follows:

    1) Reset the shift register to all zeroes
Loop:
    2) Set the data input high
    3) Clock the shift register
    4) Set the data input low
    5) Clock the shift register 7 times
goto Loop;

The method of using one pin would be implemented by feeding the
microcontroller pin into a 3-Bit binary counter which feeds into a 3-
to-8 decoder.

I've been warned against using the one-pin method, people telling me
that I could lose sync if "a bit of static" or "a bit of noise" gets
in.

For my own project board, I went with the one-pin method. I left the
board on overnight for three nights in a row and I never lost sync
(don't ask me how many million times the display flashed). The only
way it ever loses sync is if I terminate the connection to the piezo
speaker while the piezo speaker is on (this has the effect of clocking
the shift register).

So I've two questions:

1) Should we worry about "noise" and "static", or should we rely on
the chips doing their job perfectly? Also, does interference only
occur on the chip's external pins, or can it occur within the chip
itself? If it can occur within the chip then it would seem that
microcontrollers are a lost cause... I mean what's the point in
writing a program if you can't rely on the microcontroller to execute
it reliably?

2) What do you think could be causing the shift register to clock when
I terminate the connection to the piezo? If I turn the piezo on and
off in software then I don't have the same problem, it only occurs if
I physically sever the connection, and it only happens when the piezo
is on. Someone suggested putting a capacitor in parallel with the
piezo but I'd like to understand what this would do.

Tom�s � h�ilidhe wrote:

> A lot of you are familiar with the method of using a shift register to
> multiplex a matrix of LED's.
> 
> My college project this year was to make a Connect4 game consisting of
> a 7x6 matrix of LED's.
> 
> I had two choices for implementing the display:
>    1) Use two pins from the microcontroller
>    2) Use one pin from the microcontroller
> 
> The technique of using two pins would be something like as follows:
> 
>     1) Reset the shift register to all zeroes
> Loop:
>     2) Set the data input high
>     3) Clock the shift register
>     4) Set the data input low
>     5) Clock the shift register 7 times
> goto Loop;
> 
> The method of using one pin would be implemented by feeding the
> microcontroller pin into a 3-Bit binary counter which feeds into a 3-
> to-8 decoder.
> 
> I've been warned against using the one-pin method, people telling me
> that I could lose sync if "a bit of static" or "a bit of noise" gets
> in.
> 
> For my own project board, I went with the one-pin method. I left the
> board on overnight for three nights in a row and I never lost sync
> (don't ask me how many million times the display flashed). The only
> way it ever loses sync is if I terminate the connection to the piezo
> speaker while the piezo speaker is on (this has the effect of clocking
> the shift register).

Some other things that could upset the state, that you might not have tried:

- Wiggle the power connector such that the power is briefly interrupted.

- Zap the exposed parts with some static electricity. You can charge 
yourself on a carpet. For best effect, hold some metal object like a 
screwdriver, and tap your device with it.

- Plug some heavy duty electrical equipment into an outlet on the same 
strip, and quickly power cycle it, or wiggle the prongs in the outlet.

- Put your cell phone near the device, and call it.

> 1) Should we worry about "noise" and "static", or should we rely on
> the chips doing their job perfectly?

I've a question for you: When was the last time anything was perfect?

The question is your How much imperfection can you tolerate?  That will tell 
you how much you need to guard against imperfection.

JJS

On May 6, 11:44 am, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> A lot of you are familiar with the method of using a shift register to
> multiplex a matrix of LED's.
>
> My college project this year was to make a Connect4 game consisting of
> a 7x6 matrix of LED's.
>
> I had two choices for implementing the display:
>    1) Use two pins from the microcontroller
>    2) Use one pin from the microcontroller

You keep avoiding the question:
What wrong with using 13 pins?
There are tons of uC with more than 13 pins.

Tom�s � h�ilidhe wrote:
> A lot of you are familiar with the method of using a shift register to
> multiplex a matrix of LED's.
> 
> My college project this year was to make a Connect4 game consisting of
> a 7x6 matrix of LED's.
> 
> I had two choices for implementing the display:
>    1) Use two pins from the microcontroller
>    2) Use one pin from the microcontroller
> 
> The technique of using two pins would be something like as follows:
> 
>     1) Reset the shift register to all zeroes
> Loop:
>     2) Set the data input high
>     3) Clock the shift register
>     4) Set the data input low
>     5) Clock the shift register 7 times
> goto Loop;
> 
> The method of using one pin would be implemented by feeding the
> microcontroller pin into a 3-Bit binary counter which feeds into a 3-
> to-8 decoder.
> 
> I've been warned against using the one-pin method, people telling me
> that I could lose sync if "a bit of static" or "a bit of noise" gets
> in.
> 
> For my own project board, I went with the one-pin method. I left the
> board on overnight for three nights in a row and I never lost sync
> (don't ask me how many million times the display flashed). The only
> way it ever loses sync is if I terminate the connection to the piezo
> speaker while the piezo speaker is on (this has the effect of clocking
> the shift register).
> 
> So I've two questions:
> 
> 1) Should we worry about "noise" and "static", or should we rely on
> the chips doing their job perfectly? Also, does interference only
> occur on the chip's external pins, or can it occur within the chip
> itself? If it can occur within the chip then it would seem that
> microcontrollers are a lost cause... I mean what's the point in
> writing a program if you can't rely on the microcontroller to execute
> it reliably?
> 
> 2) What do you think could be causing the shift register to clock when
> I terminate the connection to the piezo? If I turn the piezo on and
> off in software then I don't have the same problem, it only occurs if
> I physically sever the connection, and it only happens when the piezo
> is on. Someone suggested putting a capacitor in parallel with the
> piezo but I'd like to understand what this would do.

You can still use the one pin method and have "zap proof" recovery.
You can shift out enough zero data to ensure that all LEDs have been
cleared and then shift out your desired pattern.  You control the 1's.

On May 6, 10:21=A0pm, Electroniker <no...@wrenchman.com> wrote:

> You can still use the one pin method and have "zap proof" recovery.
> You can shift out enough zero data to ensure that all LEDs have been
> cleared and then shift out your desired pattern. =A0You control the 1's.


Please show me how you'd do this using only one microcontroller pin.

On May 6, 9:11=A0pm, linnix <m...@linnix.info-for.us> wrote:

> You keep avoiding the question:
> What wrong with using 13 pins?
> There are tons of uC with more than 13 pins.


Well they only microcontroller I've ever worked with is the PIC16F684,
and it has 12 pins to play with. That's the only reason. I'm new to
embedded systems so I don't have much clue about what microcontroller
to pick for the job.

On May 6, 8:30=A0pm, "John Speth" <johnsp...@yahoo.com> wrote:
> > 1) Should we worry about "noise" and "static", or should we rely on
> > the chips doing their job perfectly?
>
> I've a question for you: When was the last time anything was perfect?


The PC I'm typing on right now is perfect. It's working exactly as
intended. When I press "e", an "e" appears on the screen. Even if I
press "e" one million times I'll still only ever get an "e". That's
perfect.


> The question is your How much imperfection can you tolerate?


Well if something could go wrong *inside* my microcontroller then I'm
f**ked. If a register changes from 100 to 110 then the whole program
will behave erratically, perhaps even setting pin values that will
result in a short circuit that will burn out components.

If something can only go wrong on the pins *outside* of the chips,
then I suppose it isn't too bad if my LED matrix has a dodgy flash
once every couple of weeks. It'd be a bit much though if it happened
once every minute.

On May 6, 8:18=A0pm, Arlet Ottens <usene...@c-scape.nl> wrote:

> Some other things that could upset the state, that you might not have trie=
d:
>
> - Wiggle the power connector such that the power is briefly interrupted.
>
> - Zap the exposed parts with some static electricity. You can charge
> yourself on a carpet. For best effect, hold some metal object like a
> screwdriver, and tap your device with it.
>
> - Plug some heavy duty electrical equipment into an outlet on the same
> strip, and quickly power cycle it, or wiggle the prongs in the outlet.
>
> - Put your cell phone near the device, and call it


Will all of these things only result in erratic behaviour on the
*outside* of the chips, i.e. on the pins. If it were to result in
erratic behaviour *inside* the chip, then what hope have we? I mean if
a register's value gets changed then the program will go haywire.

Tom�s � h�ilidhe wrote:

> A lot of you are familiar with the method of using a shift register to
> multiplex a matrix of LED's.
>
> My college project this year was to make a Connect4 game consisting of
> a 7x6 matrix of LED's.
>
> I had two choices for implementing the display:
>    1) Use two pins from the microcontroller
>    2) Use one pin from the microcontroller
>
> The method of using one pin would be implemented by feeding the
> microcontroller pin into a 3-Bit binary counter which feeds into a 3-
> to-8 decoder.
>
> I've been warned against using the one-pin method, people telling me
> that I could lose sync if "a bit of static" or "a bit of noise" gets
> in.
>
> For my own project board, I went with the one-pin method. I left the
> board on overnight for three nights in a row and I never lost sync
> (don't ask me how many million times the display flashed). The only
> way it ever loses sync is if I terminate the connection to the piezo
> speaker while the piezo speaker is on (this has the effect of clocking
> the shift register).
>
> So I've two questions:
>
> 1) Should we worry about "noise" and "static", or should we rely on
> the chips doing their job perfectly? Also, does interference only
> occur on the chip's external pins, or can it occur within the chip
> itself? If it can occur within the chip then it would seem that
> microcontrollers are a lost cause... I mean what's the point in
> writing a program if you can't rely on the microcontroller to execute
> it reliably?
>
> 2) What do you think could be causing the shift register to clock when
> I terminate the connection to the piezo? If I turn the piezo on and
> off in software then I don't have the same problem, it only occurs if
> I physically sever the connection, and it only happens when the piezo
> is on. Someone suggested putting a capacitor in parallel with the
> piezo but I'd like to understand what this would do.

This is the hardware equivalent of the two copy problem. Open sync
is a bad design idea. Assume in your design that it will
fail to sync at some point and have a way to resync as part of the design
even using a second micro to drive the display or choose a
micro suitable for the task.

Micro's cost is very similar to small shift or decoders.

w..