> On Tue, 6 May 2008 19:24:07 -0400, the renowned Robert Adsett
> <sub2@aeolusdevelopment.com> wrote:
>
>> In article <4a022b33-2119-4a50-a20f-5bf963cb1365@
>> 25g2000hsx.googlegroups.com>, Tom�s � h�ilidhe says...
>>> 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).
>> 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
>> ** Posted from http://www.teranews.com **
>
>
> Ah, the "Madman Muntz" school of cost reduction.,
>
> http://en.wikipedia.org/wiki/Madman_Muntz
>
> 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.
> 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.
>> You control the 1's.
>
> Please show me how you'd do this using only one microcontroller
> pin.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Reply by Spehro Pefhany●May 7, 20082008-05-07
On Tue, 6 May 2008 19:24:07 -0400, the renowned Robert Adsett
<sub2@aeolusdevelopment.com> wrote:
>In article <4a022b33-2119-4a50-a20f-5bf963cb1365@
>25g2000hsx.googlegroups.com>, Tom�s � h�ilidhe says...
>> 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).
>
>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
>** Posted from http://www.teranews.com **
Ah, the "Madman Muntz" school of cost reduction.,
http://en.wikipedia.org/wiki/Madman_Muntz
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
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
> On May 6, 10:21 pm, 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. You control the 1's.
>
>
>
> Please show me how you'd do this using only one microcontroller pin.
On May 6, 2:57 pm, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> On May 6, 9:11 pm, 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.
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.
Reply by Robert Adsett●May 6, 20082008-05-06
In article <4a022b33-2119-4a50-a20f-5bf963cb1365@
25g2000hsx.googlegroups.com>, Tom�s � h�ilidhe says...
> 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).
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
** Posted from http://www.teranews.com **
> On May 6, 8:18 pm, Arlet Ottens <usene...@c-scape.nl> wrote:
>
>> 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
>
>
> 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.
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.
> 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".
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.
> 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.
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.
>
> 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.
...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
> 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..