Dwayne Reid wrote:

> At 10:46 PM 2/21/2005, Russell McMahon wrote:
> 
>> In a real world things change. Murphy brings electrostatic discharge, 
>> power supply glitches, power supply sags, battery spikes, .... .
>> IF a pin tied high or low changes to an output the processor will 
>> sink/source appropriately. This may not matter at all. And it may 
>> cripple the product. It MAY cause physical damage to the processor. It 
>> MAY cause a battery to flatten far far sooner than it ought. And it 
>> may not. Code or hardware changes may short the open or open the short 
>> - the pin's unused so nobody may notice.
> 
> 
> I see no problem with leaving unused I/O pins un-connected and set as 
> output.
> 
> Some have mentioned the supposed problem of the pin floating for the few 
> microseconds at startup until the code gets around to setting the TRIS 
> registers.  I fail to see how that is a problem.

Lets see now. The input impedance of a gate is 10^12 ohms.
An external EM field of a few volts/meter could easily swing that gate
above threshold in a few microseconds. If you do not have appropriate
pulldowns the gate operates,  firing the explosives.
Of course you have an interlock for explosives, but probably not
for H bridge FETS.

> Others have mentioned the potential problem of an ESD event or other 
> glitch flipping a TRIS bit such that the un-used pin becomes an input.  
> While this might become a problem if it were never dealt with, prudent 
> design suggests that all static registers (set only during 
> initialization) should be refreshed on a periodic basis.  After all, if 
> a glitch might turn an unused I/O pin into an input, who is to say that 
> a similar glitch might not change some other register that would 
> actually affect operation?
> 
> In summary - easiest method of dealing with unused I/O pins is to leave 
> them unconnected and set as output.

So which method is more reliable in the long term?
Setting a register and forgetting about it, or refreshing it
regularly, with the possibility that the refresh screws it up?

In high reliability operations, how does one ensure that
the executable code is 'correct'? Do you checksum or CRC it WHILE
you are running? What about data EEPROM or RAM?  At what point does
the checking process make the device LESS reliable? And if the code
is found to be faulty some time after start up do you just STOP running
(fireworks controller) or keep going (pacemaker)?

I have a project in the works and am torn between the simplicity of
just CRC'ing the executable as part of the startup initialization,
and running a continuous code verification. Seems to be that it is
just as probable that the code check routine could screw up as
the mainline code. I don't have the luxury of having 2 copies of the
code to hot restart into.

And this also opens up the discussion of the wimpy PIC watchdog timer.
Any watchdog that just requires a single hit, rather than the $55
then $AA banging of the HC11 et al, can't be that useful since
it's possible to get into a loop that just bangs the watchdog.

Any comments from experienced (burned) engineers appreciated.

Robert

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