Pin won't turn off properly
Russell McMahon email (remove spam text)
> >Now imagine that the transistor base is driven directly by a port pin
> >no drive resistor. This is very bad practice but will work.
> >When port pin is low the base is low and transistor is off.
> >Read the port pin and you will see a logic low, as you would expect.
> Huh? You just said "This is very bad practice but will work".
> In this case, the designer gets a bad result because of a bad design.
> That's not the fault of the micro at all - it's the designers fault.
Sorry - I was trying to use a simple example that was clear enough to be
sure to explain how the affect happens.
What I meant was bad HARDWARE practice. It may in fact be legitimate from a
spec sheet point of view.
More generally - in real world situations you can not always guarantee that
the pin will be loaded as you hope or intend or even design it to be. If you
are willing to acept that your program may misbehave or lock up if
unexpected external situations occur then you don't need to use a shadow
register. If you want your program to always function as intended
independent of external conditions then a shadow register is a simple and
easy and low resource cost solution. You still have to decide what action
the program should take if the unexpected hardware conditions alter what the
hardware does BUT the program itself always works as intended.
Example. My PIC drives a MOSFET gate directly. The pin connects directly to
the gate. This is entirely within spec sheet requirements and is good
hardware practice with an appropriate FET. Imagine that the program sets the
gate high, does something else then makes a decision depending on whether
the gate is high or low. If the MOSFET suffers a ftal failure the gate may
become connected to source and be a hard ground. This is a not uncommon
failure mode (believe me :-) !). In this case, if the program makes the
high/low gate decision by reading the port pin then it wil decide that the
port is low. The port is indeed low - BUT the drive signal is high. My
program may loop forever and "hang" the program. While neither decision will
make the dead FET work, having the program make the desired decision rather
than making one based on an erroneous hardware situation, is liable to be
superior. Obviously you have to have thought this through to get a fully
useful program. (What do I do if th FET is dead .... ? )
Designing a program this well may well be too much effort for many people.
But the shadow register is liable to "save your skin" in many less dramatic
Note that it MAY be acceptable (depending on data sheet specs for the given
device) to use a port pin to drive a load which loads it so heavily that the
pin can not be driven to a guaranteed high level. Such a result is a design
decision which can be made if you have enough information available. In such
cases, use of a shadow port GUARANTEES that you will know what your port is
being driven to do externally. Reading the port itself will not tell you
> The shadow port is unnecessary in this case IF the designed did their job.
> Fixing "faulty" code this way (in this case) is just avoiding the cause.
No. As above. While writing "good" code is not a substitute for proper
hardware design, the aim is to make your software as immune as is easily
possible, to real world events. The shadow register does this with minimal
cost and effort. I have used shadow ports on processors which require them
for many years and have never regretted doing so. On processors which are
specifically designed to overcome the "pin loading" shortcoming (eg AVRs)
the shadow port is not needed as long as the instructions used utilise the
provided ports appropriately.
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
See also: www.piclist.com/techref/ubicom/devices.htm?key=sx
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the