Prev: Bug in latest IAR MSP430 compiler optimization???
Next: Simple Clockable Decoder Chip
From: Hans-Bernhard Bröker on 6 May 2008 18:32
Tom�s � h�ilidhe wrote:

> The PC I'm typing on right now is perfect.

Most certainly not.

> 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.
From: Arlet Ottens on 6 May 2008 18:41
Tom�s � h�ilidhe wrote:
> On May 6, 8:18 pm, Arlet Ottens <usene...(a)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.

From: linnix on 6 May 2008 16:11
On May 6, 11:44 am, Tomás Ó hÉilidhe <t...(a)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.
From: linnix on 6 May 2008 22:49
On May 6, 2:57 pm, Tomás Ó hÉilidhe <t...(a)lavabit.com> wrote:
> On May 6, 9:11 pm, linnix <m...(a)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.

From: Tomás Ó hÉilidhe on 6 May 2008 17:56
On May 6, 10:21 pm, Electroniker <no...(a)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.
 |  Next  |  Last
Pages: 1 2
Prev: Bug in latest IAR MSP430 compiler optimization???
Next: Simple Clockable Decoder Chip