'PICs: Good Design versus what (usually) works - T'
|I'll grandiosely consider this a tutorial.
Shoot me if I tutor wrong.
I may not make friends here but I consider this matter is vital to good
I here reject the holy writ of "PICs are robust, you can safely use the
protection diodes to clamp beyond-rail signals" which is a fallacy.
Even MChip have actively defended a circuit which violated this principal,
rather than listen to reasoned discussion (Engineer's test tool -
correspondence posted here in the last year). .
This is a discussion related to producing designs which meet data sheet
specifications versus one's which "usually" work. By all means criticise
what I'm saying if I'm wrong - do it on list - this is on topic (how rare
:-)) and PIC related and is important to new designers trying to ensure that
their designs will be "guaranteed" to work. Of course, no such guarantee
exists but this is the minimum standard for real world designs. I have used
only one "preliminary" 16F84 data sheet here but every 16F84 data sheet I
have seen for years has had this stamped across it. By all means point out
data sheets with different specs.
Russell McMahon said:
> MANY people over time on this list have supported the use of the PIC's
> internal diodes to clamp signals to an acceptable level.
> DON'T DO IT.
> The PIC is guaranteed "safe" at up to 20ma protection diode current.
> The PIC is NOT guaranteed to work properly with ANY protection diode
William Chops Westfield <CISCO.COM> said billw
>There's a MICROCHIP App Note (AN521) that uses the internal protection
>diodes to allow a PIC to be connected to AC mains voltage using only a (5M)
>resistor. They mention a +/-500uA allowable current (into/out of an input
>pin) which is backed up by a number in that "absolute maximum" section of
>the specs (for 16C54, in my 1992 databook.)
>Has microchip retracted that app note?
And Russell sez -
What I can say is that, taking one data sheet as an example, this design
definitely violates the chips GUARANTEED operating conditions.
This doesn't mean that it WON'T work - just that, if it doesn't, then MChip
will just laugh at you.
I personally would not consider that the presence of a figure on an
"absolute maximum" table as backing up a design that reaches that condition
during normal operation. YMMV.
This MAY be (ie appears to me to be) an example of an "Application Engineer"
doing what everyone
KNOWS works as opposed to sticking to what a MChip designer has (almost)
guaranteed will work in the spec sheet.
Taking a randomly selected "preliminary" but apparently complete 1998 16F8X
sheet (DS30430C page 73) I see under ABSOLUTE MAX ratings that voltage on
any pin may be Vss-0.6V and Vdd+0.6V. Such a voltage will nominally ONLY
JUST inject current into the protection diodes.
They don't say under abs max specs whether it will still work - in fact they
explicitly say that it may not and that values in operations listing section
must not be exceeded for guaranteed operation.
In the same data sheet page 77 under DC characteristics Vinlow is clearly
stated as Vss < Vin < xxx where xxx varies depending on various conditions.
The lower limit is ALWAYS FORMALLY stated as Vss. This is Microchip's
guarantee. Similarly Vinhi has a max value of Vdd in EVERY case.
We all KNOW that we can extend this range.
If (when) it malfunctions MChip are not to blame.
If we want to flash a LED then, no problem.
If we want to control aerobraking into Mars orbit then we best stay within
spec (and use metric units for our thruster force calculations :-)).
>(and where are people getting this "20mA" number, which I only see as
>maximum output current for an OUTPUT pin, with nothing about the
On page 73 of the same data sheet (the abs max page mentioned above)
it specs "input clamp current" as +/- 20ma max for Vi < 0 or Vi > Vdd.
I don't know if this spec is in older data sheets but it may be as it is the
same current as mentioned by others.
Abs max i/o current sunk is 25ma and sourced is 20mA. This doesn't
necessarily relate to the clamping current spec.
All this is only one aspect of PIC design but it approaches an Analog one. I
have personally experienced improper and intermittent PIC operation when
violating the above conditions using a circuit provided by a software
supplier to allow direct RS232 interface to a PIC. I knew that this was a
"naughty" approach but it still took significant time before I realised that
it was the cause of my apparently intermittently operating software. YMMV
but ultimately you too will get bitten.
Lay on Macduff :-)
>From another world - http://www.easttimor.com
What can one man* do?
Help the hungry at no cost to yourself!
(* - or woman, child or internet enabled intelligent entity :-))
As for myself, and I have been designing and fabricating electronic circuits
for over 20 years, I wouldn't attempt to interface the Inputs and Outputs of
ANY micro-controller or microprocessor directly to the outside world. That
would violate every precaution I was ever taught plus it is just plain common
sense. The very very minute cost of either diodes, transistors, or buffers
ICs is just not worth destroying your project.
Well, again that is my $.02 worth on the subject, nuf said by me.
The subtle problem of being able to set the state of a OUTPUT
pin by noise which may occur during a Read/Modify/Write to another
pin in the same port, is worth emphasising again (periodically)
so any 'newbies' don't get 'bit' by it as many of us have at
OUR time. I notice one (at least, ...) 'unmentionable' <G.>chipmaker
now adds another register to the port logic to try to avoid this.
Maybe we could all stop politic-ing long enough to but together
a 'gotchas' list. We could co-locate it with the PICList Archive.
"Randy A." wrote:
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...