Searching \ for 'Unused PIC Pins - What to do with them?' 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: 'Unused PIC Pins - What to do with them?'.

Truncated match.
PICList Thread
'Unused PIC Pins - What to do with them?'
1999\01\16@213635 by Geoff Thornton

flavicon
face
Piclisters I have been following the thread "Unused PIC Pins tied to
Ground - Input or output" with some interest as I am new to PICs, and admit
the thread has left me somewhat confused. What exactly is the recommended
procedure for dealing with uncommited PIC pins?


Regards Geoff :)
==================
spam_OUTgeoffTakeThisOuTspamtechie.com

1999\01\16@223734 by paulb

flavicon
face
Geoff Thornton wrote:

> What exactly is the recommended procedure for dealing with uncommited
> PIC pins?

 Well, firstly, the thing *not* to do is to tie them to VCC or ground.

 If you don't want to connect them to *anything*, make them outputs.
It is probably not too critical what you write to them.

 They default to inputs.  If they are on Port B and it suits you to
do so, just leave them as inputs and turn on the Port B pull-ups.  These
pull-ups only apply to inputs so if they happen to be re-defined as
outputs, there will be no current drain either way unless you connect
something else.

 If you think you *may* want to use them later as inputs, and you will
not be using port B pull-ups, you may want to tie them high with a SMD
resistor in the meantime and leave them as inputs.

 If you have one or two pins quite uncommitted, why not add a SMD LED
and series current limit resistor (4k7 or 10k).  Then you can either use
this as a COP (Computer Operating Properly) indicator flashing at 1 Hz
when the main program is executing correctly, or have it flash at
critical points, or flash codes as a diagnostic while debugging the
program.

 Have I missed anything?
--
 Cheers,
       Paul B.

1999\01\17@065033 by Andy Stephenson

flavicon
face
Leave them unconnected.

Do not connect them to VDD or VSS.

If you have room / cost add a pull up or pull down res. You don't have to
fit them in the final unit, but if you suddenly need a switch input - it's
there waiting for you.

If you choose to leave the lines totally unconnected, set them as outputs
in your software.

By doing this, you give yourself room for manouver (...spelling?) to catch
any last minute fixes.

Just my ten cents.

Rgds...

...Andy
At 12:33 17/01/99 +1000, you wrote:
{Quote hidden}

1999\01\17@070941 by Gerhard Fiedler

picon face
At 14:35 01/17/99 +1000, Paul B. Webster VK2BZC wrote:
>Geoff Thornton wrote:
>
>> What exactly is the recommended procedure for dealing with uncommited
>> PIC pins?
>
>[almost complete comments snipped :-)]
>
>  Have I missed anything?

what i usually do with a free pin (without emulator) is using it as a
serial out (which can be done pretty lowscale, if not intended for
production), and then put debugging messages out there. even if there's no
space for serial comms with the complete code, it's handy for testing parts
of the code separately and quite conveniently.

ge

1999\01\18@022809 by ruben

flavicon
face
I always leave unused pins unconnected and configured as outputs. That way
it is easy to use them for something (mostly debugging) that wasn't planed
at the beginning. This, I think, is common practice. What I also do, and
have not seen mentioned here before, is to frequently read the value of the
outport and write it back. This way the pin won't be destroyed if it is
forced low when written high (short circuit to ground or something), instead
the pin state is switched to whatever it is forced to externaly.

{Quote hidden}

==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +4640142078
FAX INT +4640947388
.....rubenKILLspamspam.....2.sbbs.se
==============================

1999\01\18@122419 by Gabriel Gonzalez

flavicon
face
Basically, leave them unconnected, but set them as outputs in software.

Gabriel

-----Original Message-----
From: Geoff Thornton <EraseMEgeoffspam_OUTspamTakeThisOuTTECHIE.COM>
To: PICLISTspamspam_OUTMITVMA.MIT.EDU <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Date: Saturday, January 16, 1999 7:31 PM
Subject: Unused PIC Pins - What to do with them?


>Piclisters I have been following the thread "Unused PIC Pins tied to
>Ground - Input or output" with some interest as I am new to PICs, and admit
>the thread has left me somewhat confused. What exactly is the recommended
>procedure for dealing with uncommited PIC pins?
>
>
>Regards Geoff :)
>==================
>KILLspamgeoffKILLspamspamtechie.com

1999\01\25@140300 by John Payson

flavicon
face
|Piclisters I have been following the thread "Unused PIC Pins tied to
|Ground - Input or output" with some interest as I am new to PICs, and
|admit the thread has left me somewhat confused. What exactly is the
|recommended procedure for dealing with uncommited PIC pins?

With two caveats, typing them directly to ground is a bad idea; leaving
them open and setting them to outputs is the beast idea.

Caveat number 1: if the device will spend any significant amount of time
in a 'reset' state and is running off of batteries (or there is some
other reason why minimal-power operation is desirable) the device may use
more power than normal because of the floating port pins.  Note that this
caveat does not apply to analog-configurable pins on devices which have
them (such as the 16C62x and 16C7x).

Caveat number 2: The RTCC pin on the 16C5x is input-only, and on the other
PICs, the pin (RA4/TMR0) is open-collector and can only output a low sig-
nal.  Thus, on the 16C5x RTCC should probably be tied to either ground,
VDD, or /MClr if it's not used for anything else; on the 16Cxx you may
safely ground the pin or tie it to /MClr if you don't mind being unable to
use it for a 'debug' or future expansion.

If you are concerned about power consumption while the device is in reset,
or if pin RA4/TMR0 may be wanted as an output, using individual pull-up
resistors to VDD may be the best way to go if the cost and space are not
objectionable.  If you are using resistor packs to pull up other inputs
and you have extra resistors available, you may as well take advantage.

1999\01\26@041557 by paulb

flavicon
face
Ruben Jšnsson wrote:

> What I also do, and have not seen mentioned here before, is to
> frequently read the value of the outport and write it back.

 I would say you have not seen it mentioned before because most would
consider it a Bad Thing.  It's a rather bizarre design philosophy to
set outputs to match glitches, and the most important lesson learned
about the PIC is to avoid read-modify-write operations like the plague!

> This way the pin won't be destroyed if it is forced low when written
> high (short circuit to ground or something), instead the pin state is
> switched to whatever it is forced to externaly.

 Good design focusses on making sure that will never happen.  If you
think it *may* happen, you use current-limiting resistors.  You might
perhaps read the port and if it is stuck opposite to what was written,
TRIS it to an input and send out a fault message.

 Otherwise, your suggested read may pick up a glitch and write the
output wrongly so that it does the very thing you were trying to avoid.
--
 Cheers,
       Paul B.

1999\01\26@084554 by ruben

flavicon
face
Well, this trick has saved me many windowed PIC's when I am in the
breadboard stage of a new design. At the beginning of a new project
I usually start with only part of the complete circuit leaving me
a lot of unused I/O pins. When I have got the core of the software
working I add more hardware and software bit by bit until the whole
thing is finished. Between the first stage and the finished working
prototype is mostly a lot of testing and changing of both hardware
and software. Needless to say, it has happened more than once that
an unused or used output by accident has been connected to a low
impedance source. The read and write back, especially on unused I/O's
set as outputs, saves the PIC in this case.

Another case where the read and write back is useful is when doing
fault mode and effects analysis on some type of safety circuits. Here
it is sometimes required to test and document what is happening when
shorting every pin on one IC with every other pin on the same IC. The
read-modify-write has saved many circuits here. A current limiting
resistor wouldn't help much in this case.

Bad design philosophy, however, is to let glitches affect your program
flow. When reading I/O's I always make sure, by good circuit design,
hardware and/or software filters, that what is read is not a glitch.
(I can't say that I have ever seen a glitch affect an unused,
unconnected I/O pin set as an output anyway.)

Things to watch out for with read-modify-write:
High load on an output pin. If the load is so high that the voltage
on an high output pin is not higher than the pin is read back as low
it won't work.

Settling time. Especially with capacitive load.
If a portpin is changed and the output is read back before
it is settled there will be no change.


With these things in mind I will happily continue my
read-and-write-back scheme, which has saved me more than
it has caused me trouble.

{Quote hidden}

==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +4640142078
FAX INT +4640947388
RemoveMErubenTakeThisOuTspam2.sbbs.se
==============================


'Unused PIC Pins - What to do with them?'
1999\02\10@080117 by electme
flavicon
face
ruben ,
where you said
"What I also do, and
have not seen mentioned here before, is to frequently read the value of the
outport and write it back. This way the pin won't be destroyed if it is
forced low when written high (short circuit to ground or something), instead
the pin state is switched to whatever it is forced to externaly."

thats a good idea.
how do you do it .for 16f84 & 12c508
glen
*******
Ruben Jšnsson wrote:

{Quote hidden}

1999\02\11@021954 by ruben

flavicon
face
Hello Glen,

This is mostly taken care of automatically (even if You want it or not)
by the read/modify/write function of I/O pins of all PIC processors.
That is, when you modify a pin in a port by clearing or seting a bit, the
whole port byte is first read, the bit is updated and the whole byte is
written back to the port. When the port value is first read it is the
logical level on the pin that is read and not the output latch in the PIC.

If You have unused output pins in a port and want them to follow what ever they
are externaly forced to just make sure You update another bit in the
port often enough without explicitly seting the unused output bit. If no bit in
port is modified often enough this can be done by MOV PORT_X,f which reads
the portvalue and writes it back again. Any forced output pins will then
change state. Be ware, though, that this may have unwanted effects on used
IO pins which shouldn't be allowed to change it's state. To overcome this,
use a shadow register in ram for the port and whenever the portvalue is to
be updated, modify it first in the shadow register, read the portvalue,
mask off the used pins, OR the result with the shadow register (which
should have the unused bits set to 0) and write it back to the port.
This way only the unused pins will change their state to whatever they are
forced to externaly.

Good luck

{Quote hidden}

==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +4640142078
FAX INT +4640947388
RemoveMErubenspamTakeThisOuT2.sbbs.se
==============================

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