- Jan 1, 1970
Obviously there are cases where the extra cent won't make it worthwhile.
But consider this: what if YOU are not the programmer working on the
device? Things change, people change. It's very likely that firmware will
be changed by someone else, someone who may not have the experience,
someone who test benches new firmware, notes everything is fine, releases
the firmware to the field, and all of a sudden hundreds of dead devices
are being returned. Why? The specific conditions that set the port to zero
(when tied to one, or vice versa) were never seen during this
inexperienced programmers testing.
If I've designed a piece of equipment for a client, and it works like
it's supposed to, then I've done my job and everyone is happy. If,
then, someone comes along behing me and starts trying to make changes
without knowing what they're doing, it certainly doesn't reflect
badly on me, it reflects badly on whoever was supervising the idiot
Consider the costs then??
Why should I care? I didn't have anything to do with the failures.
Or consider this: MCUs aren't infallible, do ugly things to the power
rails or expose them to ESD and it's very possible for the port direction
control bits to flip. Even strong RF can do it.
So what? If those are eventualities which are to be expected in the
field, then the proper time to address them is during the design, and
if it's prudent to add pullups or pulldowns it should be done as part
of the process, but certainly not blindly, and _cedrtainly_ not
because some idiot may come along and screw with your code.