Loss of synchronisation: Are the chips reliable?

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.

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

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

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.

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

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.

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.

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.

d:

Will all of these things only result in erratic behaviour on the

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..

...but you forgot to explain here how the one wire system is implemented!

Any system that relies on a Power-reset action, and then assumes thereafter 'everything is ok' IS a risky design. ESD events, and noise spikes from mains contacts are common disturbance sources.

If all that happens is your display 'loses the plot', then the user will likely respond with a power-cycle.

Microsoft would consider that a "Shippable Quality Standard"

Ford and Toyota, probably would not.

There are plenty of ways to build a SYNC/reset into a one wire clocking system. Feed the CLK into the CTR reset, via a RC circuit, and then eg: holding CLK HI for a 'long time' will reset the device, whilst a clock that is mostly low, with narrow positive pulses will simply clock. If the CTR is +ve reset, the taking the CAP to +5V will also give an element of POR. That type of design, can resync under software control.

-jg

Most certainly not.

So you believe. But you're wrong. The odds that a given PC's keyboard will actually withstand 1 million depressions of the 'e' key and work every single time are slim at best.

And that's why you should *not* design your circuits in a way that allows such desastrous shorts to happen. Running LEDs without current limiting resistors is one way of inviting desaster.

With good design practices you can protect yourself from all these events. For example, brown-outs can be handled by keeping the MCU in a reset state whenever the power supply voltage is below a certain threshold. It is quite common for this circuitry to be included in the microcontroller itself. So, for a single chip, this particular problem can be solved.

With additional chips on the board, the problem is much more complicated. What if a brown-out only resets the MCU, but not your shift register ? Or the other way around, it only resets the shift register, but not your MCU? Or even worse, it changes some random bits in the shift register, and may or may not reset the MCU.

If the MCU has some means to bring the rest of the board into a known state, the solution is to make sure the MCU always resets first, and have it reset the rest of the board during initialization. It's even better if the rest of the board doesn't have any independent state, but is directly controlled by the MCU for every action.

That reminds me of a cost reduction process I saw. The fellow removed a cap, repowered the device and watched it start successfully. Scratched that cap off the BOM and repeated....

Robert

For 10 more cents, go get the PIC16F677 or something like that. It got 18 pins. Try it and be done with your headache and those headaches you are giving us.

Some reading on 1 wire BUS systems :

and a new one, the Uni/O

LIN bus is another 1 pin IO standard.

and, there are bus designs that use the 3 state's of a typical uC port, as another encoding system. Low, Light Hi, for CLK, and Hard-Hi for RST.

-jg

Ah, the "Madman Muntz" school of cost reduction.,

By trial and error, Muntz developed a television chassis that produced an acceptable monochrome picture with just 17 tubes. He carried a pair of wire clippers around and when he thought one of his employees was "overengineering" a circuit, he would begin snipping components out until the picture or sound stopped working. At that point, he would tell the engineer "Well, I guess you have to put that last part back in" and walk away.

I wonder what he'd have done if he saw a modern FPGA with several hundred bypass capacitors.

Best regards, Spehro Pefhany

For a simple example, ship UART codes (10 sequential bits) producing 8 bits. Use 3 to control position (i.e. which LED block) and 5 to control the bits. No persistent errors. Rep. rate depends on UART speed.

Probably the same as the Chinese do...