On 29 Mar 2017 at 9:06, James Wages wrote:

> Tue, 28 Mar 2017, "Brent Brown" wrote:
>     If all your PIC circuits are bread-board or other "in the lab" type a=
pplications, then=20
>     yes they may well work acceptably. But somewhere else like say an ind=
ustrial=20
>     environment, then yes you are correct - expect noise issues.
>    =20
> Let's assume an industrial environment where noise is a concern.=20
> More specifically, let's assume a 12-volt automotive electrical
> system.  What are the noise implications that should be considered
> when using large pull-up resistances when the PIC is running at low
> voltages (3.0V and under), and where the PIC's inputs are connected
> to DIP switches that switch to Ground (i.e., nothing where timing is
> critical)?  Is there a realistic cap on how large the pull-up should
> be in light of the said noise?  (I assume the noise we are speaking
> of here is something that would throw a PIC input pin into an
> undesired and unexpected state, correct?)=20
=20
There are no hard and fast limits/rules for pull-up value. You've loosely s=
tated the=20
environment, but noise level is still anyone's guess. I get the idea you ar=
e leaning=20
toward choosing the highest possible pull up resistance, is it that you are=
 concerned=20
about power consumption when a DIP switch is on? What a realistic power=20
consumption would be in your application is not possible to decide without =
more=20
information. Resistors are the same price regardless of Ohms, err on the lo=
w side=20
for more margin, if you can.

Noise is unlikely to be much of a problem when your switch is on (R ~=3D 0 =
Ohms).=20
When switch is open you'll nominally see 3V DC on your PIC input thanks to =
your=20
pull-up, but noise if/when present noise will cause it to fluctuate (more R=
 =3D more=20
noise). First problem is obviously when the noise causes the voltage to dip=
 low=20
enough that your PIC reads the input as digital state 0 instead of 1. Secon=
d problem=20
is when the noise is large enough to start causing the PIC's input diodes (=
to Vss=20
and Vdd) to conduct, pushing your micro outside of specified operating cond=
itions=20
(expect un-expected operation, excessive power consumption, latch-up, pushi=
ng up=20
of Vdd, possible other nasty stuff).

Input de-bouncing in software is one thing you can do that is cheap (zero p=
arts=20
cost). In addition adding capacitive filtering and/or Schmitt trigger can h=
elp. These=20
address the first problem.

Adding series resistance and/or clamp diodes helps with the second problem.=
=20
Beyond that more accurate under/over voltage protection networks may be=20
necessary to completely prevent violation of the PICs input specs. But all =
of these=20
are a bit over the top for just a DIP switch and short PCB traces.

Once upon a time I helped debug a dashboard mounted keypad in an automotive=
=20
environment. The symptom was random key presses while driving. Turned out t=
he=20
de-bounce code had a bug in it, and effectively wasn't de-bouncing at all.=
=20
Fortunately we were able to re-create the problem in the workshop by sparki=
ng a=20
DC supply onto a transformer winding, and pin-pointed the problem by moving=
 wires=20
close to the keypad. After tweaking the de-bounce code we were then able to=
=20
demonstrate the problem had been completely fixed, moreover keypad operatio=
n=20
couldn't be faulted with noise an order of magnitude or two higher.

Spending an hour or two getting de-bounce code demonstrably working well in=
 the=20
first place is good cheap engineering.


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.