Searching \ for '[PIC] What to do with unused pins?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'What to do with unused pins?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] What to do with unused pins?'
2007\07\29@200748 by Forrest W Christian

flavicon
face
Is there any recommendation on what to do with the unused pins on a PIC
to limit potential problems and/or unneeded power drain?  I.E. tie them
to ground, tie them to VCC, let them float, set them all to outputs,
etc.   Most IC's seem to have a recommendation this way (I.E. tie unused
inputs to ground, or specific recommendations for specific pins), but I
don't seem to be able to locate any for the PIC's.

I'm looking for both the official recommendation (if there is one), and
what others have done and whether or not it's caused problems.

Thanks.

-forrest

2007\07\29@202229 by Jinx

face picon face
www.piclist.com/techref/logic/xtrapins.htm

2007\07\30@091147 by David VanHorn

picon face
Might be easier to say what NOT to do with them:  Don't leave them as
inputs without pullups on.

It's ok to leave them as inputs, as long as they have internal chip
pullups, or external pullups.

Most people set them as outputs, and whether they sit high or low
seems to be a religious war :)

2007\07\30@094003 by Mike Hord

picon face
The old hands on the list will have seen this message about 200 times,
and many many many of them (including one grumpy fellow out in
Massachusetts)(right?) get a little twist in their britches each time they
see it.  In all the complaining and RTFM'ing surrounding this question,
AND in all of the polite responses to it, I've never seen the following
point brought up:

Realizing that this question needs to be asked in the first place is a
good sign that the person in question understands some of the
subtleties of electronics design and very possibly is well on his/her
way to being a pretty good engineer.  I suspect more people ask this
question in the form "Why is my micro doing X?" which then turns
out to be related to a floating input.

At any rate, leave 'em inputs and tie 'em high or low through a
resistor (10k is good), or make 'em outputs and set 'em high or low.

And to head off the OTHER most popular RTFM questions, not that
I think you need the answers but just because they bear repeating:
RA.4 is an open-collector output; it can NOT drive the pin high.
Most PICs have a minimum required voltage for erase.  If a flash
chip seems to be giving you one-time-use errors (or verify errors
after the initial programming run) you may need to up the supply
voltage.
Put a bypass cap on the power supply (~.1uF) across the Vdd/
Vss pins as close to the chip as possible.

Mike H.

On 7/29/07, Forrest W Christian <spam_OUTforrestcTakeThisOuTspamimach.com> wrote:
{Quote hidden}

2007\07\30@101500 by Russell McMahon

face
flavicon
face
> At any rate, leave 'em inputs and tie 'em high or low through a
> resistor (10k is good), or make 'em outputs and set 'em high or low.

BUT the inputs with resistors is the better of the two if you can
afford the real estate (because it has essentially NO failure modes,
whereas the 'outputs' solution does). .

{Quote hidden}

NEVER us a port pin to store "state information" and then
read-modify-write the pin and expect it to always work. Instead, keep
a "mirror" of the pin state, modify that and then write the result to
the port each time. {{ If the pin is over-loaded externally so that eg
a high in the output register does not produce a high on the pin then
when the port is read a low may be seen when a high is meant to be
present. In such a case a read-modify-write of the pin may produce an
erroneous result. [[This problem may not exist with some processors
but if you don't know if it exists with the processor that you are
using then Murphy will make sure that it applies (provided it's
important enough that it shouldn't). }}


(n)    Never never never never allow the body diodes (protection
diodes on each pin) to conduct * under any circumstances when the
processor is intended to operate normally. If you do allow this do not
be surprised if it fails to operate normally during OR after this
event until it has been COMPLETELY powered down. Resetting and
allowing Vdd to fall to say 0.6V does not constitute "completely
powered down".

(n+1)    Never even start to listen to people who try to explain that
the point above is incorrect or unnecessary, no matter how experienced
or qualified they may be or seem to be. If you start to listen you may
end up believing them, and thereby be lost.

(n+2)    :-).

Part of my standing mission in life is to attempt to ensure that
people who care, believe point (n). There appears to be a group of
people, some apparently well qualified and / or experienced, who, for
reasons that totally escape me, seem to have the opposite mission in
life.

* There will be a current level where this is in fact safe. This
current level will usually be > 10 uA and may sometimes be 100 uA
(bank holidays) or in some cases even 1 mA (blue moons). The actual
value will change with processor, machine state, general circuitry,
phase of the moon and the price of fish. If you can establish the safe
level to an extent that works for you in all cases that matter then by
all means allow the body diodes to conduct this level of current if
you must. In all other cases, stay clear.




       Russell






2007\07\30@113830 by wouter van ooijen

face picon face
> BUT the inputs with resistors is the better of the two if you can
> afford the real estate (because it has essentially NO failure modes,
> whereas the 'outputs' solution does). .

IMHO that is an invalid argument. If your work is so error-prone that
you can't remember that certain pins must be configured as outputs and
not connected to anything, you should not be doing embedded stuff (I am
not sure you should be doing other stuff either). Or you should avoid
using *any output pins at all* (for if you can err on the unused pins,
you can just as easily err on the used ones - maybe you should avoid
using input pins too, bacause you might erroneously make them outputs),
but I can't think of many designs that follow that rule and are still
usefull.

The 'use the pin later for an as-yet unforseen purpose' argument is
valid, but whether it has enough weight depens on your circumstances.
For me it never had.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\30@120905 by Alan B. Pearce

face picon face
>IMHO that is an invalid argument. If your work is so error-prone
>that you can't remember that certain pins must be configured as
>outputs and not connected to anything, you should not be doing
>embedded stuff (I am not sure you should be doing other stuff either).

I took it to mean that there is always the possibility of code malfunction,
that could cause the pins to be left as inputs, instead of outputs as they
were supposed to be, not so much as an error prone argument.

For this purpose I do like Olins modules, which are set up to make any
unused pin a digital output, if not configured in any way in the
configuration file.

2007\07\30@131907 by wouter van ooijen

face picon face
> I took it to mean that there is always the possibility of
> code malfunction,
> that could cause the pins to be left as inputs, instead of
> outputs as they
> were supposed to be, not so much as an error prone argument.

"unused pins should be inputs with pull-ups" is IMHO valid only if the
design is protected agains all errors that have roughly the same chance
of ocuuring. IMHO pins that are supposed to be inputs are equally liable
to become outputs, so the design should be protected against that too. I
seldom see designs that are.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\30@132429 by David VanHorn

picon face
> I took it to mean that there is always the possibility of code malfunction,
> that could cause the pins to be left as inputs, instead of outputs as they
> were supposed to be, not so much as an error prone argument.

When the chip is in reset, the pins will be inputs. Micros are done
that way so that you can use pulling resistors (up or down) to assure
they are in the "safe" state for your application during reset or
programming.

2007\07\30@134909 by David VanHorn

picon face
> "unused pins should be inputs with pull-ups" is IMHO valid only if the
> design is protected agains all errors that have roughly the same chance
> of ocuuring. IMHO pins that are supposed to be inputs are equally liable
> to become outputs, so the design should be protected against that too. I
> seldom see designs that are.

But you have known points where those pins WILL be inputs, regardless
of what code is loaded in. During reset and programming, for example.
If the system isn't designed to put those pins into a "safe" state,
bad things will happen.  Inputs that are floating, and not
schmidt-triggered can get into the middle states during programming
too.

As far as runtime, I usually have a "sanity check" routine running
that will detect some fault conditions, and put the output pins into a
"safe" state, in a routine called "Halt_And_Dont_Catch_Fire"   There's
only so much you can really do in that regard, but it's relatively
easy to do it.

At least nobody can accuse me of using uninformative labels.
:)

2007\07\30@141331 by James Newtons Massmind

face picon face
> > BUT the inputs with resistors is the better of the two if you can
> > afford the real estate (because it has essentially NO
> failure modes,
> > whereas the 'outputs' solution does). .
>
> IMHO that is an invalid argument. If your work is so
> error-prone that you can't remember that certain pins must be
> configured as outputs and not connected to anything, you
> should not be doing embedded stuff (I am not sure you should
> be doing other stuff either).

Firmware softens. Not often, but it happens. Especially with bootloader
firmware updates.

Not to mention that authors typo during development.

If the output pin is directly tied to ground and set low, or to Vcc and set
high, a glitch will fry the chip.

If the output pin is left floating, a glitch may prevent a bootloader from
reloading good firmware.

If the output is resistively tied to something, why not leave it an input?

In short, stuff happens. It's good to have padding on the sharp edges.

---
James.


2007\07\30@143846 by Hector Martin

flavicon
face
What are the chances of an unused floating input pin causing problems
with the micro? I understand that this is a Bad Idea (TM) in most cases,
but I've had one case recently where I couldn't think of an alternative.

I recently gave a robotics workshop, where the attendees built little
robots based on a control board we provided them with. The board had a
few built-in systems and a bunch of extra I/O pins to let the user
experiment. This was built for lowest cost and build time (we built the
~18 or so boards manually), so elaborate protection circuits and the
like are out of the question - if it breaks, deal with it or replace the
PIC.

The problem is what to do with the pins. They have to default to inputs,
of course - for one thing, that's what the PIC does, and I can't risk
setting them to outputs and having someone short them against something.
I can't add pull-up or pull-down resistors, as which is more appropriate
(if any) depends on the application, and they would screw up analog
measurements. The bootloader also has to run with zero knowledge of the
application that will run, and during that time the pins have to be inputs.

The question is, other than a possible increase in power draw (I can
deal with that - the PIC is running at 40Mhz and sucks quite a bit of
power anyway), what are the chances of malfunction? I've heard all sorts
of stories about PICs going crazy due to floating inputs, but that
doesn't make much sense - pins ARE inputs when the program starts up,
and if malfunction is possible this would require pull-ups or -downs on
*every* output pin to guarantee correct operation, at least until the
TRIS bits get set and the internal pull-ups enabled, if needed.

--
Hector Martin (.....hectorKILLspamspam@spam@marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\07\30@145431 by William \Chops\ Westfield

face picon face

On Jul 30, 2007, at 10:49 AM, David VanHorn wrote:

> you have known points where those pins WILL be inputs, regardless
> of what code is loaded in. During reset and programming, for example.

This would apply to "used" outputs as well, though.  Surely not all
pins have to be wired to deal with the fact that they'll be inputs
at some brief times during the product's existence...

BillW

2007\07\30@154946 by Forrest Christian

flavicon
face
Ok, since it looks like I stepped in a landmine due to my apparent
inability to google for the right FM to read (hint: "unused PIC *pins*"
not "unused PIC *ports*"), I guess I better reply to myself after R-ingTFM.

These are the options I see, with my commentary on each:

1) Floating Input:  Not good on any design, which is the reason why I
asked.  Let's not go there.

2) "Shorting" to Ground or VCC.  This is common practice on unused gates
of standard logic (aka 7400 series), since the inputs will stay
inputs.   This practice can cause physical failures on PIC's since
inputs aren't necessarily always inputs, and if an "input" gets set to
an output, then absolute maximum ratings on pins can be exceeded (pin
current) and an otherwise salvageable with a reflash device gets toasted.  

3) Setting all pins to output and letting them float:   This practice
works on a PIC, except when software fails and causes a floating output
to become a floating input.  This is probably the best option if there
is no real eastate or budget for pullup/pulldown resistors.   Note that
software fails is taken with a liberal meaning and includes such things
as bootloaders not settting pins correctly and the like.   However,
depending on the design this may or may not be high risk.  This also
ignores ICD (which isn't relevant to my design).

4) Setting all pins to input, and pulling them high or low through
appropriate resistors.   This works if you can afford to do so (real
estate and/or price)   The choice between high and low seems to slightly
favor low since it sounds like low has slightly less Iq, and an argument
can be made that a short to ground is more likely than a short to VCC.  
The advantage of this over #3 is that if an input is erroneously set to
an output the PIC will still survive, provided sufficiently large
pullup/down resistors.  The main disadvantage that I can see is board
real estate and costs related to the resistors themselves (component +
insertion).

5) The engineer in me wonders if I should also consider a fifth option
of pulling the ports down and also setting them as permanently low
outputs.   This would solve software failures, and if a resistor was
missing, you would not have a floating input to deal with.  This may
gain the best of both worlds.  Assuming that there isn't something bad
about a pulldown resistor on a low output (I would be at a loss to
figure out what it would be).   Of course there's the inverse of this as
well.

One real problem is what to do with B6 and B7 (the ICD pins) in an
circuit with an ICD header......  I'll go dig some more to figure this
out, although I know the CCS docs say don't connect anything but the ICD
tool to these two pins.

I'll probably design for 4, and then play with 5 a bit.   (After all,
it's only a software change)

Thanks for all the input.

-forrest

2007\07\30@163953 by David VanHorn

picon face
On the AVR, a short to VCC or ground isn't fatal, and I'm a little
surprised if that is indeed fatal on the PIC.  Most of these devices
use mosfets with relatively high on resistances as pin drivers, and
they self-limit to reasonable values.

Also, a shorted pin on a production board is already a "broken" board.
For a hobby thing, it's far more likely, and it would be nice if it
didn't kill anything.

2007\07\30@164421 by David VanHorn

picon face
> This would apply to "used" outputs as well, though.

Sure. In fact the outputs are potentially more interesting.
Printers in particular, don't like to have their hammer drivers or
thermal head elements turned on for more than a few hundred
microseconds at a time.
That's where I initally started using "Halt_and_dont_catch_fire".  The
routine sets all the important outputs to what should be safe values,
and sits there till reset happens.

> Surely not all
> pins have to be wired to deal with the fact that they'll be inputs
> at some brief times during the product's existence...

If they aren't schmidt triggers, then they can get into a state where
the high and low transistors on the input buffer are on.  That makes
the input pin draw more current than it should, and can cause
unexpected issues in other areas of the chip. I've seen it cause chips
to act "dead", or unable to program, depending on the type of chip.

2007\07\30@164857 by wouter van ooijen

face picon face
> If the output pin is directly tied to ground and set low, or
> to Vcc and set high, a glitch will fry the chip.

If you are serious about this, you can't connect a pushbutton switch to
a PIC pin. Or any chip output that has a serious drive capability.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\30@173211 by David VanHorn

picon face
> If you are serious about this, you can't connect a pushbutton switch to
> a PIC pin. Or any chip output that has a serious drive capability.

Realistically, there should be significant series resistance between
the switch and the processor for ESD protection anyway.

2007\07\30@174450 by James Newtons Massmind

face picon face
> > If the output pin is directly tied to ground and set low, or to Vcc
> > and set high, a glitch will fry the chip.
>
> If you are serious about this, you can't connect a pushbutton
> switch to a PIC pin. Or any chip output that has a serious
> drive capability.

If a switch is normally closed to ground or Vcc and the input pin is
accidentally (firmware fail, programmer error, etc...) set to drive against
that, it will destroy the chip, as you say. That configuration is rare in my
experience.

Most switches are normally opened so if the firmware goes wacko and sets the
pint to an output, it will only be damaged if the button is pressed. Which
is less likely, but still possible.

Design for maximum ruggedness and recovery from failed firmware update would
require that switches be connected to ground via a resistor with a much
larger resistor for the pull up against the switch. In most applications
that probably isn't worth doing, but if you are making a device that with
firmware which will regularly be updated by the user and unit cost /
warranty are strong forces, adding that low value resistor to the switch
could be a very good idea.

Same with bread boarding / development systems. Knowing how often I screw
things up when initially writing code, I like to protect the hardware from
my brain farts as much as possible. I tend to be very good with the problem
solving and with troubleshooting while at the same time being pretty
terrible with the details of what pins is which and so on.

---
James.


2007\07\30@180704 by William \Chops\ Westfield

face picon face

On Jul 30, 2007, at 1:44 PM, David VanHorn wrote:

> If they aren't schmidt triggers, then they can get into a state where
> the high and low transistors on the input buffer are on.  That makes
> the input pin draw more current than it should, and can cause
> unexpected issues in other areas of the chip.

So are floating inputs likely to cause any permanent failures of
the chip, or just temporary less-than-optimal behavior?  We're
talking about ensuring "correct" operation of software that's
broken?  Can't happen; it's already broken.  And hopefully a
chip designed for ICSP can at least do ICSP regardless of the
pin states of pins not involved in ICSP...  Unless there's the
chance of more permanent issues, I don't think you have to worry
about ensuring appropriate pins states during correct "normal"
operation...

BillW

2007\07\30@184217 by peter green

flavicon
face
David VanHorn wrote:
> On the AVR, a short to VCC or ground isn't fatal, and I'm a little
> surprised if that is indeed fatal on the PIC.  Most of these devices
> use mosfets with relatively high on resistances as pin drivers, and
> they self-limit to reasonable values.
>  
Shorting a pin to ground or vdd and then driving it the other way
violates the absoloute maximum ratings of the pic. However the
impression i get is that in practice you will get away with it provided
its just one or two pins but if its lots of pins you may well fry stuff.

the pics also have unusually high output drive capabilities (arround
20ma iirc) which works against them in the case of such faults.


2007\07\30@191054 by Xiaofan Chen

face picon face
On 7/30/07, David VanHorn <microbrixspamKILLspamgmail.com> wrote:
> > If you are serious about this, you can't connect a pushbutton switch to
> > a PIC pin. Or any chip output that has a serious drive capability.
>
> Realistically, there should be significant series resistance between
> the switch and the processor for ESD protection anyway.

Especially for AVRs which in general is more susceptible than PICs. ;-)

Yes I agree it is better to have a series resistor. Normally I will put a small
cap acorss the pushbutton/switch as well.

Xiaofan

2007\07\30@193943 by Carl Denk

flavicon
face
Was said:
> Most switches are normally opened so if the firmware goes wacko and sets the
> pint to an output, it will only be damaged if the button is pressed. Which
> is less likely, but still possible.
>  
Not necessarily, in alarm systems, it's normal to have the switch closed
on normal operation, and open if there is a fault. That way if a wire
breaks, there is an alarm.

2007\07\30@214305 by Russell McMahon

face
flavicon
face
>> BUT the inputs with resistors is the better of the two if you can
>> afford the real estate (because it has essentially NO failure
>> modes,
>> whereas the 'outputs' solution does). .

I don't think that we fundamentally disagree on anything here.

> IMHO that is an invalid argument. If your work is so error-prone
> that
> you can't remember that certain pins must be configured as outputs
> and
> not connected to anything, you should not be doing embedded stuff (I
> am
> not sure you should be doing other stuff either).

I didn't say HOW the error modes occur - just that they exist.
ie an unused pin with a resistor to Vss of Vdd can be put in any
available pin state without problems. A hard connected pin can't. The
error state may occur from aprogramming oversight or from a glitch.

As example ONLY - worst case in some design s if a number of pins were
hard grounded and then accidentally driven high by a glitch (perhaps
from current flowing in a body diode :-) ) then the processor might
not recover at all. This would be an extreme case but possible.

All I said was that a mode that CANNOT fail is better than one that
has that possibility.

> Or you should avoid
> using *any output pins at all* (for if you can err on the unused
> pins,
> you can just as easily err on the used ones - maybe you should avoid
> using input pins too, bacause you might erroneously make them
> outputs),
> but I can't think of many designs that follow that rule and are
> still
> usefull.

If you were building equipment for eg a Martian orbiter I imagine that
you'd try rteally really really hard to make a design that could have
ANY pin glitch into any state at any time while absolutely minimising
impact. This MIGHT include driving inputs from sources that have
impedances high enough that they constitute a valid load if the pin
changed to an output. It's not, as you suggest, usual, but it's
conceivable that in some cases one would want to do this.

> The 'use the pin later for an as-yet unforseen purpose' argument is
> valid, but whether it has enough weight depens on your
> circumstances.

Agree. As I said " ... if you can afford the real estate ... ". If the
solution value is inadequate you may wish to avoid it, even if it is
technically superior.



{Quote hidden}

> --

2007\07\30@214305 by Russell McMahon

face
flavicon
face
This thread, or a competent summary of it, should be required reading
for all wouild be Green-belt (not the city sort) and above
microprocessor developers. .

Once you can discourse on this competently you get to start on the
protection diodes topic.



       Russell

2007\07\30@231638 by Jinx

face picon face
> This was built for lowest cost and build time (we built the ~18 or so
> boards manually), so elaborate protection circuits and the like are
> out of the question - if it breaks, deal with it or replace the PIC

Hector, if you don't mind me saying, that's a short-sighted view. A few
resistors is good insurance, and cheaper, than the cost and effort to
replace a PIC

> The problem is what to do with the pins. They have to default to inputs,
> of course - for one thing, that's what the PIC does, and I can't risk
> setting them to outputs and having someone short them against something

But didn't you just say "if it breaks, deal with it or replace the PIC". If
you don't want to use resistors, then minimise the capability for the pins
to be shorted

> I can't add pull-up or pull-down resistors, as which is more appropriate
> (if any) depends on the application, and they would screw up analog
> measurements. The bootloader also has to run with zero knowledge of
> the application that will run, and during that time the pins have to be
inputs

Depending on the noise in the environment, 100k or more would do if
you really insist on having pins as unconnected inputs. 100k+ shouldn't
interfere too much

> The question is, other than a possible increase in power draw (I can
> deal with that - the PIC is running at 40Mhz and sucks quite a bit of
> power anyway), what are the chances of malfunction?

Depends which pin. People have reported all sorts of strange behaviour.
Also, with no "stabilising" component present it's quite possible for O/S
voltages to enter the PIC.

> I've heard all sorts of stories about PICs going crazy due to floating
> inputs, but that doesn't make much sense - pins ARE inputs when the
> program starts up, and if malfunction is possible this would require
> pull-ups or -downs on *every* output pin to guarantee correct
> operation, at least until the TRIS bits get set and the internal pull-ups
> enabled, if needed.

PIC datasheets do say that inputs should not be left floating. Microchip
realise what is required for, as you say, "guaranteed correct operation"

The time between power-up and TRIS being set is generally very short.
It is possible that external conditions could exist in that time-frame that
would cause the pin to latch/fry before pins are set to outputs. You are
gambling with software beating hardware. Mostly you'll win, sometimes
you won't

2007\07\30@234550 by David VanHorn

picon face
> > Realistically, there should be significant series resistance between
> > the switch and the processor for ESD protection anyway.
>
> Especially for AVRs which in general is more susceptible than PICs. ;-)

???  That's been true since I started using micros. 8051, Z-80 PIO,
all need external ESD protection.

> Yes I agree it is better to have a series resistor. Normally I will put a small
> cap acorss the pushbutton/switch as well.

Yes, agreed.

2007\07\30@234916 by David VanHorn

picon face
> Shorting a pin to ground or vdd and then driving it the other way
> violates the absoloute maximum ratings of the pic. However the
> impression i get is that in practice you will get away with it provided
> its just one or two pins but if its lots of pins you may well fry stuff.

Ok, understood.   And in cases like this, it's important to understand
the mechanism behind the limitations. "Don't do this" is much less
useful than "If you do this, it causes that to happen, and that's
bad".

2007\07\30@235923 by Peter

flavicon
face


Jinx wrote:
{Quote hidden}

Hector /Jinx,
I was commissioned to design, a "simple" battery operated widget,
sometime back.  The owner of the project, had these short sighted views,
"...nope can't have any extra resistors onboard, keep it small and cost
down..." they would say.  I submitted my original very power efficient
design, which followed Jinx's method, of "...A few resistors is good
insurance, and cheaper,..." (all SMD 603 design).  The design just
worked..! I couldn't get it to fail under any conditions.

The bean counters came in and forced out the "...so called NOT NEEDED
extras..".   However, the design worked in testing.  They said, see it
works!!  I said, "you'll be sorry..!!"  Later, down the track, when
manufactured,... what happened, ...strange things started, to occur, in
different units.  When push came to shove, the failure was tried to be
pinned on me, but because I kept very detailed notes, the project owner
had to wear this big miss judgment.  My point is,...."...A few resistors
is good insurance, and cheaper,..." Never overlook this!
I have seen it too many times.  One can cost cut but sometimes,.....!

Peter

2007\07\31@000750 by Peter

flavicon
face


David VanHorn wrote:
>>> Realistically, there should be significant series resistance between
>>> the switch and the processor for ESD protection anyway.
>>>      
One of our engineer's left out ESD protection in a design, killed a 1500
pin BGA FPGA... ouch...!


2007\07\31@031515 by wouter van ooijen

face picon face
> All I said was that a mode that CANNOT fail is better than one that
> has that possibility.

That's exactly what I disagree with. IMHO it does not make sense to
throw any effort (hardware or softwere or wetware) at avoiding a failure
mode if you can't also avoid all other failure modes that have a similar
chance of ocurring.

> If you were building equipment for eg a Martian orbiter I
> imagine that
> you'd try rteally really really hard to make a design that could have
> ANY pin glitch into any state at any time while absolutely minimising
> impact.

*If* your design does this *then* I would agree that tying unised pins
high or low with a resistor makes sense. But only *if*.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@031515 by wouter van ooijen

face picon face
> > Shorting a pin to ground or vdd and then driving it the other way
> > violates the absoloute maximum ratings of the pic. However the
> > impression i get is that in practice you will get away with it
> > provided its just one or two pins but if its lots of pins
> you may well
> > fry stuff.
>
> Ok, understood.   And in cases like this, it's important to understand
> the mechanism behind the limitations. "Don't do this" is much
> less useful than "If you do this, it causes that to happen,
> and that's bad".

But remember that the fact that the manufacturer does not allow some
condition (in this case, a high current) for a particular reason, gives
him full freedom to chance his design, so tomorrow that condition might
cause a different failure mode. So insight might be usefull, but you'd
better not rely on it. This is especially true with Microchip who uses
3d party fabs so they change fabs and process more often than other
manufacturers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@031516 by wouter van ooijen

face picon face
> This practice can cause physical failures on PIC's since
> inputs aren't necessarily always inputs, and if an "input"
> gets set to
> an output, then absolute maximum ratings on pins can be exceeded (pin
> current) and an otherwise salvageable with a reflash device
> gets toasted.  

Again, if you take this serious you can't connect *any* output with
serious drive capability (directly) to  PIC pin.

> One real problem is what to do with B6 and B7 (the ICD pins) in an
> circuit with an ICD header......

you can pull them low with a realy high impedance (let's say 220k).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@063522 by Michael Rigby-Jones

picon face


>On Jul 30, 2007, at 1:44 PM, David VanHorn wrote:
>
>> If they aren't schmidt triggers, then they can get into a
>state where
>> the high and low transistors on the input buffer are on.  That makes
>> the input pin draw more current than it should, and can cause
>> unexpected issues in other areas of the chip.

>{Original Message removed}

2007\07\31@065938 by Russell McMahon

face
flavicon
face
>> If you were building equipment for eg a Martian orbiter I
>> imagine that
>> you'd try rteally really really hard to make a design that could
>> have
>> ANY pin glitch into any state at any time while absolutely
>> minimising
>> impact.

> *If* your design does this *then* I would agree that tying unised
> pins
> high or low with a resistor makes sense. But only *if*.

Best I've managed along those lines is a conceptual design for a Lunar
lander :-).

But, there are real world situations where the system may be fragile
enough that trying to stop a potentially recoverable glitch become a
full fatality may be worth the effort. Or may not depending on cost,
importance, available room, phase of moon, wetness of fish, ... . An
example might be a processor system running on a low capacity battery
with a very long target lifetime. Battery impedance may be high enough
and battery voltage close enough to no-go as the end of life
approaches that a high current glitch may cause premature system
failure. Examples might be a container data logger, some sort of long
life timer, a battery operated alarm  transmitter etc. This is a
somewhat contrived example but not an especially unrealistic one.

But, going back to what I said originally.
All I said, implied, suggested and adumbrated was:

- The functionally technically best solution is the one that uses some
hardware (a resistor per pin) to ensure that an illegal condition can
never happen.

- Whether this solution is worthwhile depends on whether the extra
cost is worth the gain in a given case. Cost includes components, PCB
area, manufacture, test, ... .

I'm a bit surprised that people seem to want to argue with these
points. They are NOT saying that its the solution you should always
use, must use, will be using if your mother doesn't wear army boots or
whatever. It's fine if the cost benefit doesn't work or has never
worked for you for whatever reason. That doesn't affect the technical
merit of the solution.


       Russell

2007\07\31@070856 by Russell McMahon

face
flavicon
face
The horse surely looks dead now, but I'll give it another wack just in
case.

> It's very easy to say "it's just a few resistors", but if you are
> approaching board densities where you are struggling to put down the
> last few 0402 resistors that the design actually requires to
> function, then pull downs on unused pins become the first
> casualties.  It's been frequently mentioned on the list that
> refreshing TRIS and LATCH/PORT registers regularly is a good idea
> anyway, on the off chance that ESD etc. could potentially cause a
> flipped bit.  If this is done, then simply setting unused pins to
> outputs at your preferred logic level should be perfectly safe.
/>

For many values of perfectly :-)
ie will usually work so well in practice that the frequency of
occurrence of bad failure modes is so low as to be acceptable.

If you are building Martian or other spacecraft (and at least one
member on this list is) then you may strike values of "perfectly well"
that cost you your mission. The more so in a higher radiation
environment where random bit swapping can be a significantly increased
hazard, depending on other design decisions.



       Russell





2007\07\31@072940 by microbrix

picon face
You've been "muntzed".

On 7/30/07, Peter <.....Great_Pic_nKILLspamspam.....westnet.com.au> wrote:
{Quote hidden}

> -

2007\07\31@075315 by Xiaofan Chen

face picon face
On 7/31/07, Michael Rigby-Jones <EraseMEMichael.Rigby-Jonesspam_OUTspamTakeThisOuTbookham.com> wrote:
>
> It's very easy to say "it's just a few resistors", but if you are
> approaching board densities where you are struggling to put
> down the last few 0402 resistors that the design actually requires
> to function, then pull downs on unused pins become the first casualties.

Very true.

Board real estate is a real issue now. The customer wants smaller
and smaller design or double the functionality without increase the
size. Then there is always cost reduction project going on forever.
It is getting more and more difficult. Sometime this will
result to marginal design. To me this is not very healthy. However
if other vendors are doing similar things and you have to follow.

Somehow I think European vendors are doing a better job
in terms of reliability. Maybe that is part of the reason they
are suffering more from the competiition.


Xiaofan

2007\07\31@080104 by Gerhard Fiedler

picon face
Jinx wrote:

> The time between power-up and TRIS being set is generally very short.
> It is possible that external conditions could exist in that time-frame that
> would cause the pin to latch/fry before pins are set to outputs.

Is this really true? What conditions are these? (I'm assuming normal
operation conditions here. Of course you can fry an input pin and more with
mains voltage, but then a pull-up wouldn't help much either :)

What about programming a chip? Most programmers don't pull up/down all
unused pins, but still power up the chip.

Gerhard

2007\07\31@080507 by Gerhard Fiedler

picon face
Russell McMahon wrote:

> All I said was that a mode that CANNOT fail is better than one that
> has that possibility.

When talking about very low probability failure modes, it may be important
to consider the possible failures that an additional component (or a few)
introduces. It may be mounted wrong, for example, in hand-mounted very
tight SMD boards that can't have meaningful a silk screen.

I don't think there is a mode that cannot fail :)

Gerhard

2007\07\31@082959 by Michael Rigby-Jones

picon face


{Quote hidden}

That is undoubtedly the bottom line.  Even with pull ups/downs, should the pin be switched into an output, the possible extra current draw on a low power design could cause premature failure, i.e. the battery dies sooner than anticiapted.

If you do the best you can within the constraints you've been given, then there should be no problems sleeping soundly at night.  Assuming your design isn't keeping someone alive or piloting a nuclear warhead of course.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\07\31@084018 by Hector Martin

flavicon
face
Jinx wrote:
> Hector, if you don't mind me saying, that's a short-sighted view. A few
> resistors is good insurance, and cheaper, than the cost and effort to
> replace a PIC

With "elaborate protection circuits" I wasn't referring to a resistor.
Say, a Zener based voltage protection with a resistor to limit current,
a resistor to pull up, and a bypass jumper for analog usage. That sort
of thing is out of the question. I was talking about the general case,
not only the floating inputs problem.

> But didn't you just say "if it breaks, deal with it or replace the PIC". If
> you don't want to use resistors, then minimise the capability for the pins
> to be shorted

Say someone wires up a bumper as a normally-closed switch to +5V and I
decide to set the default to output 0. That would not be good :)

> Depending on the noise in the environment, 100k or more would do if
> you really insist on having pins as unconnected inputs. 100k+ shouldn't
> interfere too much

100k would work with most digital inputs and some analog inputs. There
are some things it disables though. Note that these are boards for
people to experiment with. One little experiment we tried was setting
the motor PWM value to the ADC value read from an input. Then, you can
touch the analog input with your finger, and depending on whether you
touch Vcc, GND, or a combination (with varying pressure), you end up
with an extremely simple speed control. It's also a good test of the PWM
outputs and analog inputs, with zero extra hardware.

> Depends which pin. People have reported all sorts of strange behaviour.
> Also, with no "stabilising" component present it's quite possible for O/S
> voltages to enter the PIC.

How? As I said, I've never had any trouble with floating inputs. That
doesn't mean I will leave them as that in production circuits, but it
tends to happen during testing and prototyping at times, and in cases
like this one (which can be considered a small-scale production
prototyping system). Where would an out of spec voltage come from, anyway?

> PIC datasheets do say that inputs should not be left floating. Microchip
> realise what is required for, as you say, "guaranteed correct operation"
>
> The time between power-up and TRIS being set is generally very short.
> It is possible that external conditions could exist in that time-frame that
> would cause the pin to latch/fry before pins are set to outputs. You are
> gambling with software beating hardware. Mostly you'll win, sometimes
> you won't

So that's a yes. Does everyone here place pull-up/down resistors on all
output pins then? According to Microchip, it seems to be required for
guaranteed correct operation. The bootloader would also be a problem. On
my board, there's a whole second before the user application starts up
and sets TRIS.


--
Hector Martin (RemoveMEhectorTakeThisOuTspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\07\31@084938 by wouter van ooijen

face picon face
> > The time between power-up and TRIS being set is generally
> very short.

> Is this really true?

As always, check the datasheet. There is a hardware power-up delay,
which can be enabled in the configuration word, but IIRC it is  enabled
automatically when an xtal is used. And what about a brown-out condition
in combination with an internal or external brwon-out reset, or an
external reset delay?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@084944 by wouter van ooijen

face picon face
> - The functionally technically best solution is the one that
> uses some
> hardware (a resistor per pin) to ensure that an illegal condition can
> never happen.

As far as I am concerned I don't object to that, but I try to point out
that this "functionally best" solution makes no sense when other failure
modes (with a compareable chance of ocurring) are still present.

> That doesn't affect the technical merit of the solution.

I did not argue with that. Only with the (non)sensibility of applying
this solution.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@090531 by David VanHorn

picon face
> So that's a yes. Does everyone here place pull-up/down resistors on all
> output pins then? According to Microchip, it seems to be required for
> guaranteed correct operation. The bootloader would also be a problem. On
> my board, there's a whole second before the user application starts up
> and sets TRIS.

This comes down to what the spec is, vs what you can get away with.
In the AVR it's not a problem, the I/O pins are schmidt triggered.

>From Art of Electronics, Horowitz and Hill, page 580:

"An open input of an unused CMOS gate, for instance, can float up to
the logic threshold, causing the output to go to half the supply
voltage, with both MOS output transistors conducting, thus drawing
considerable class A current. This can lead to excessive supply
current and can even lead to failure in devices with hefty output
stages. It is best to ground all inputs of unused functions on every
CMOS chip."

While this applies in a limited way to microcontrollers, it still does apply.

2007\07\31@090942 by David VanHorn

picon face
> As far as I am concerned I don't object to that, but I try to point out
> that this "functionally best" solution makes no sense when other failure
> modes (with a compareable chance of ocurring) are still present.

I don't agree with this, at least if I understand what you're saying.

Let's say that I have each failure mode as a die of N sides, so that
it's probability of occurence is that of the number "1" coming up on a
throw.

If I have 10 failure modes, then I throw 10 dice.  If I can throw nine
instead, then I've reduced my odds of seeing a "1".  Do you not agree?

2007\07\31@094552 by Jinx

face picon face
> > The time between power-up and TRIS being set is generally
> > very short. It is possible that external conditions could exist in
> > that time-frame that would cause the pin to latch/fry before pins
> > are set to outputs.
>
> Is this really true? What conditions are these?

I have read it in an app note (possibly an oscillator AN). Consider
a PIC with a slow clock. Following Tcsd it may be several 100
microseconds before TRIS can be executed. If there's noise about
and the PIC is hopping about on one leg still getting its pants on, it
would be quite possible for the silicon to be affected before s/w
can take control

2007\07\31@094552 by Russell McMahon

face
flavicon
face
> When talking about very low probability failure modes, it may be
> important
> to consider the possible failures that an additional component (or a
> few)
> introduces. It may be mounted wrong, for example, in hand-mounted
> very
> tight SMD boards that can't have meaningful a silk screen.

True.
In another lifetime I worked for the (then only) national Telco.
People proposed installing remotely operated fault isolation devices
at the boundary to customers' premises so you could test to see if the
fault was 'in' or 'out'.
BUT an analysis showed that the fault rate liable to be introduced by
the isolators exceeded the gains made by locating the faults.

> I don't think there is a mode that cannot fail :)

Indeed.
Even "stay in bed all day" while usually safish, cannot be relied on
:-)


       Russell






2007\07\31@095444 by Jinx

face picon face
> Where would an out of spec voltage come from, anyway ?

Transmitters as one example. I've had three projects that needed
extra protection. One in a plane, with a (poorly installed) 5W
transmitter not too far away, another that was vulnerable to the
RT in a taxi. Another that didn't like a weed trimmer nearby. The
one in the plane was damaged by the RF energy and had to be
replaced. The others were protected with zeners, capacitors and
resistors. Just looking at the scope it was clear that the incoming
voltage would have been O/S

Another example might be a coil collapsing, such as a relay or
solenoid

2007\07\31@095832 by wouter van ooijen

face picon face
> > As far as I am concerned I don't object to that, but I try to point
> > out that this "functionally best" solution makes no sense
> when other
> > failure modes (with a compareable chance of ocurring) are still
> > present.
>
> I don't agree with this, at least if I understand what you're saying.
>
> Let's say that I have each failure mode as a die of N sides,
> so that it's probability of occurence is that of the number
> "1" coming up on a throw.
>
> If I have 10 failure modes, then I throw 10 dice.  If I can
> throw nine instead, then I've reduced my odds of seeing a
> "1".  Do you not agree?

You have reduced your failure rate by 10%, if your estimates of the
failure rates are good.

Experience shows that failure rate estimates are often only accurate to
~ a power of 10, so even that 10% is unsure (if one of the other failure
modes happens to have a 10 times higher rate than you expect your
reduction will be only 1%).

But even if the reduction is 10% this is IME useless, unless it is part
of an effort to tackle also the other risk factors with (estimated)
compareable rates. So my bottom line is: using pull down/ups instead of
just configuring as outputs is sensible (Russel: thish is not the same
as technically best!) only when all compareable risk factors are also
addressed. At the very least this means series resistors on all switches
(when connected to PIC pins) and between PIC pins and outpust of other
chips that have a significant drive capability (I think this will
include all TTL-like chips, optocouplers, maybe also open-collector
style busses like Dallas and I2C, etc etc). When all compareable issues
are also addressed the pull up/down solution becomes (beside technically
best) also practically sound.

Note that when a failure mode with a significantly higher failure rate
is present all efforts at reducing lower-rate failure modes are a waste
of energy untill that higher rate failure mode is eliminated or reduced.
Remeber the first (or maybe second) rule about code optimization: don't
start optimizing unless you have measured what the lagest contributions
are. A programmers guess in this aspect is often wrong. IME the same
thing applies to an engineers estimate at failure reates (for a new
design, for an old design the estimates of an experienced 'old hand'
will often be dead accurate).

As a side note: I once had to find out why a design was (according to
the production line's estimates) much more expensive (compared to other
designs) than the designers expected. The way the production line
estimated the cost (correctly or not, but that's another discussion,
which was at that moment irrelevant) included a (relatively heavy) 'per
component' and 'per component type' cost. These costs represent
pic-n-place machine time, and operator time for placing a component
reel. This design in question had a lot of resistors (all the same
value) for pulling used and unused pins down, and a lot of different
resistor values (one for each value, in an analog part fo the circuit).
The designers had never realised that both contributed significantly to
the cost (at last, the cost as calculated by the production line).

I also had to do failure calculations. Using the default (add all
failure rates) calculation those pull up/down resistors were a
significant part of the overall failure rate! This is of course not
realistic, but using anything but the default calculation had to be
agreed on by the customer, which meant lots of paperwork, time (which
both contribute to the cost...)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu




2007\07\31@100814 by Jinx

face picon face
> I've never had any trouble with floating inputs

The only times I've had a floating input was the odd breadboarding
occassion when I forgot to put a pull-up on Mclr. Apart from that
I never have floating inputs, always set them to '0' outputs. Can't
recall ever shorting such an output. But you know the situation and
people you're designing for, so if the pros and cons tip the design
one way or the other and you're happy with that, then that's fine,
I'm not going to badger you about it

2007\07\31@102505 by David VanHorn

picon face
> True.
> In another lifetime I worked for the (then only) national Telco.
> People proposed installing remotely operated fault isolation devices
> at the boundary to customers' premises so you could test to see if the
> fault was 'in' or 'out'.
> BUT an analysis showed that the fault rate liable to be introduced by
> the isolators exceeded the gains made by locating the faults.

Ah yes,  THOSE things.  They caused our point of sale terminals to
"oscillate" when we went off-hook, due to the way we checked wether
the line was in use or not.  When I contacted the local telco about
it, I was told rather curtly that they would not interfere with any
part 68 approved device.. Well, a few million of ours were most
definitely impaired.

2007\07\31@103229 by David VanHorn

picon face
> Note that when a failure mode with a significantly higher failure rate
> is present all efforts at reducing lower-rate failure modes are a waste
> of energy untill that higher rate failure mode is eliminated or reduced.

Ok, I agree at this level, but I would still take easy steps to
reduce/eliminate lower risk elements if there was a higher risk
element that was hard/impossible to reduce. The return on investment
isn't as great, but it's probably worth doing.  In the end, a
judgement call.


> Remeber the first (or maybe second) rule about code optimization: don't
> start optimizing unless you have measured what the lagest contributions
> are. A programmers guess in this aspect is often wrong. IME the same
> thing applies to an engineers estimate at failure reates (for a new
> design, for an old design the estimates of an experienced 'old hand'
> will often be dead accurate).

Yes.. I've seen people go back and "optimize" init code that runs
ONCE, to remove an extra instruction.. If you are that tight on
codespace that's one thing, but if the system is wide open, (as these
were) then it's just pointless.

2007\07\31@103246 by Hector Martin

flavicon
face
Jinx wrote:
> The only times I've had a floating input was the odd breadboarding
> occassion when I forgot to put a pull-up on Mclr.
Now *that* does cause some funky behavior (I've done it too).

> But you know the situation and
> people you're designing for, so if the pros and cons tip the design
> one way or the other and you're happy with that, then that's fine,
> I'm not going to badger you about it

I'm just left wondering about how high the chance of malfunction really
is. Anyway, we'll see if anyone complains of problems before next year.
Then we'll have a new revision out. These things were actually made for
free and the parts were sponsored, and the attendees got them for free,
including the rest of the hardware (a pair of servos hacked to be
motors, a simple wooden robot chassis, and wheels and whatnot), so they
can't really demand a perfect product :)


--
Hector Martin (spamBeGonehectorspamBeGonespammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\07\31@112217 by David VanHorn
picon face
> I'm just left wondering about how high the chance of malfunction really
> is. Anyway, we'll see if anyone complains of problems before next year.
> Then we'll have a new revision out. These things were actually made for
> free and the parts were sponsored, and the attendees got them for free,
> including the rest of the hardware (a pair of servos hacked to be
> motors, a simple wooden robot chassis, and wheels and whatnot), so they
> can't really demand a perfect product :)

It's just another opportunity to learn  :)

2007\07\31@113757 by wouter van ooijen

face picon face
> Ok, I agree at this level, but I would still take easy steps
> to reduce/eliminate lower risk elements if there was a higher
> risk element that was hard/impossible to reduce.

Why? Reduce a risk from 1:100 to 1:99, where both figures have a 50%
reliability interval of, let's be optimistic, 10?

> The return
> on investment isn't as great, but it's probably worth doing.  
> In the end, a judgement call.

Been there, done some calculations. I never was the judge, but my
managers were...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@123016 by James Newton, Host

face picon face
>
> This thread, or a competent summary of it, should be required
> reading for all wouild be Green-belt (not the city sort) and
> above microprocessor developers. .
>
> Once you can discourse on this competently you get to start
> on the protection diodes topic.
>
>
>
>         Russell


I do believe it is linked from the beginners checklist at piclist.com. If it
isn't, please do add the link.

---
James Newton: PICList webmaster/Admin
TakeThisOuTjamesnewtonEraseMEspamspam_OUTpiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2007\07\31@123134 by Gerhard Fiedler

picon face
wouter van ooijen wrote:

>> Ok, I agree at this level, but I would still take easy steps to
>> reduce/eliminate lower risk elements if there was a higher risk element
>> that was hard/impossible to reduce.
>
> Why? Reduce a risk from 1:100 to 1:99, where both figures have a 50%
> reliability interval of, let's be optimistic, 10?

Maybe think in an electronics analogy. Say you want a 99.5k resistor. It
doesn't help much to put a 20M resistor in parallel to a 100k resistor if
the 100k resistor is a 5% resistor.

If 5% is enough, the 20M resistor is not necessary. If 5% is not enough,
the problem is not whether or not to add the 20M resistor, it is how to get
the 100k resistor up in accuracy (or how to individually calibrate the
devices).

Gerhard

2007\07\31@130305 by David VanHorn

picon face
> Maybe think in an electronics analogy. Say you want a 99.5k resistor. It
> doesn't help much to put a 20M resistor in parallel to a 100k resistor if
> the 100k resistor is a 5% resistor.

I see what you're saying but I still think if I can easily avoid
buying that lottery ticket, I will.  Emphasis on easily.

2007\07\31@130404 by Gerhard Fiedler

picon face
Jinx wrote:

>>> The time between power-up and TRIS being set is generally
>>> very short. It is possible that external conditions could exist in
>>> that time-frame that would cause the pin to latch/fry before pins
>>> are set to outputs.
>>
>> Is this really true? What conditions are these?
>
> I have read it in an app note (possibly an oscillator AN). Consider
> a PIC with a slow clock. Following Tcsd it may be several 100
> microseconds before TRIS can be executed. If there's noise about
> and the PIC is hopping about on one leg still getting its pants on, it
> would be quite possible for the silicon to be affected before s/w
> can take control

Hm... maybe. I don't have much experience with very slow clocks. OTOH, I'd
say that if there is enough noise to put a floating input within a few 100
us into latch-up, this is an unusual situation that possibly requires
unusual measures :)  The noise must be stronger than the leakage.

Has anybody seen this happening in real life (open pins going into latch-up
before the TRIS could be set)?

Gerhard

2007\07\31@130803 by David VanHorn

picon face
> If 5% is enough, the 20M resistor is not necessary. If 5% is not enough,
> the problem is not whether or not to add the 20M resistor, it is how to get
> the 100k resistor up in accuracy (or how to individually calibrate the
> devices).

In a similar vein, I spec 1% resistors even when I only need 20%,
because they are the same price, and better availability. There's no
downside.

2007\07\31@131608 by James Newtons Massmind

face picon face
> Even "stay in bed all day" while usually safish, cannot be relied on
> :-)


Damn.


2007\07\31@133515 by James Nick Sears

flavicon
face
On Jul 31, 2007, at 12:19 PM, Gerhard Fiedler wrote:

{Quote hidden}

Wrong.

If you need 95k (+/- 5%), you need roughly 90.25k-99.75k.  If the  
100k resistor is +/- 5%, you'll have 95k-105k.  Not good at all.  
FAIL.  Spaceship crashes.

On the other hand, If you add the 20M (+/- 5%) in parallel, you'll  
get a range of 90476 - 100000, which is much closer to what you  
desire (something like +5.3/-4.8%).

The fact that there is a tolerance for error does not negate the  
virtue in centering the error distribution on your desired value.

-n.

>
> Gerhard
>
> --

2007\07\31@134856 by James Nick Sears

flavicon
face

On Jul 31, 2007, at 1:34 PM, James Nick Sears wrote:

> Wrong.
>
> If you need 95k (+/- 5%), you need roughly 90.25k-99.75k.  If the
> 100k resistor is +/- 5%, you'll have 95k-105k.  Not good at all.
> FAIL.  Spaceship crashes.
>
> On the other hand, If you add the 20M (+/- 5%) in parallel, you'll
> get a range of 90476 - 100000, which is much closer to what you
> desire (something like +5.3/-4.8%).
>
> The fact that there is a tolerance for error does not negate the
> virtue in centering the error distribution on your desired value.
>
> -n.



Guh.  95k != 99.5k and 2M != 20M.

Nevermind.  Back to work now.

-n.

>
>>
>> Gerhard
>>
>> --

2007\07\31@134903 by wouter van ooijen

face picon face
> In a similar vein, I spec 1% resistors even when I only need
> 20%, because they are the same price, and better
> availability. There's no downside.

Yes, but that breaks the analogy. You won't get more reliable failure
rate figures even when you torture your sources. (In the analogy: sorry,
1% resistors are not avialable, or cost 10 times as much).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\07\31@182411 by Jinx

face picon face

> Hm... maybe. I don't have much experience with very slow clocks

I was reading the 4550 datasheet last night and saw that PLL start-
up holds the chip in reset for as long as 1ms until it locks, so it's not
just slow clocks

2007\07\31@225620 by John Chung

picon face
Where are you guys sourcing resistors*good quality*
from? I need them in small quantities.

Thanks,
John


--- wouter van ooijen <RemoveMEwouterspamTakeThisOuTvoti.nl> wrote:

{Quote hidden}

> --


'[PIC] What to do with unused pins?'
2007\08\01@040547 by Alan B. Pearce
face picon face
>> Even "stay in bed all day" while usually safish, cannot be relied on
>> :-)
>
>
>Damn.

Yep, I'm afraid the resulting bedsores are worse than the problems of
getting up and doing something ;))

2007\08\01@064745 by Russell McMahon

face
flavicon
face
>>> Even "stay in bed all day" while usually safish, cannot be relied
>>> on
>>> :-)

>>Damn.

> Yep, I'm afraid the resulting bedsores are worse than the problems
> of
> getting up and doing something ;))

The example that always comes to mind is flight 103 & Lockerbie :-(

A moving visit.

           http://others.servebeer.com/misc/Lockerbie.jpg
           http://others.servebeer.com/misc/Lockerbie2.jpg


           Russell



2007\08\01@085852 by David VanHorn

picon face
On 7/31/07, John Chung <kravnusEraseMEspam.....yahoo.com> wrote:
> Where are you guys sourcing resistors*good quality*
> from? I need them in small quantities.

http://www.digikey.com

2007\08\01@102626 by Marcel Duchamp

picon face
John Chung wrote:
> Where are you guys sourcing resistors*good quality*
> from? I need them in small quantities.

I get all my passives from Garrett Electronics:
http://garrettelec.com/

In addition to general all around top notch service, they put them on
reels for either a modest price or free for 500 quantity or more.

If they don't have it, then I go to Digikey, then Mouser, then where
ever I can find them.

2007\08\01@141718 by John Chung

picon face

--- Marcel Duchamp <EraseMEmarcel.duchampspamsbcglobal.net>
wrote:

> John Chung wrote:
> > Where are you guys sourcing resistors*good
> quality*
> > from? I need them in small quantities.
>
> I get all my passives from Garrett Electronics:
> http://garrettelec.com/
>
 I don mind trying them out. I would have to check
with them on shipping to Malaysia. Digikey is okay for
me*I technically send the order to a friend in
Singapore to save on shipping* . So far good service
but their have a long time to reply emails. Mouser is
something I would like to try out next :)

Thanks,
John


     
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC

2007\08\01@143531 by Marcel Duchamp

picon face
I don't know if Garrett do international shipping or not.

Just offhand, I would expect you could source parts in Asia much less
expensively than from the US.  But that's just based on impressions of
things people have stated on the list.  The reality is probably different.

It's always seems a surprise to me that products that are manufactured
in Asia and shipped to the US are often cheaper to buy than to try to
source them in Asia.  A Japanese company we worked with in the 90's
would buy Toshiba laptops from us because they were less expensive than
to get them locally in Japan.  It turned out that there is a *very*
extensive "middle-man" network there, each taking a percentage.  They
told us it was considered 'not honorable' to try to circumvent it
locally.  But buying from us in the US was apparently ok.

John Chung wrote:
{Quote hidden}

2007\08\01@151211 by John Chung

picon face
In general components in Asia is cheaper. But the
problem is that the quality is of unknown
manufacturer. I guess I can push for basic parts like
resistors and capacitors easier. Still IC chips are
something I rather order online. Easier to get lower
quantities and of a known make. Avnet is in Malaysia
but the problem is that they always order by the
100s..... I may push to ordering reels if I need too
*for basic components*. Still IC sourcing from them is
too expensive at low quantities. US always seem to
have the best deals.....

Thanks,
John


--- Marcel Duchamp <RemoveMEmarcel.duchampspam_OUTspamKILLspamsbcglobal.net>
wrote:

{Quote hidden}

> --

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...