When a simple Initialize sketch runs, or when you click New/ Upload..does it actually place all the I/O pins into a high impedance / Hi-Z tri-state condition to protect them, or does it just flip them all into an I/O input state? is the state for all unused/non-initialized I/O pins a Hi-Z state?
Assuming I fail to do this step above (like probably millions of other new Arduino users who never though about this)
How susceptible is a typical ATMEL Arduino to failure?
... if say a TTL INPUT or ground/+5Vcc jumper is left on a pin and then my new sketch code inadvertently initializes it as an output then sets it to the opposite state?
Can the pins typically tolerate this abuse? .. a lot of new especially dedicated I/O chips can, so I'm wondering if I really do need to worry much about this risk at all... Yes in the case of larger voltages and currents in Motors etc..I know that they can blow out a pin more easily but will a say typical TTL or CMOS driver or jumpered voltage or GND in contention blow the Arduino driver .. if so about what % of the time?
Upon reset, all pins are tristated, and return to their power on reset state, which is also tristated. The bootloader lights up the serial pins, but other than that, all pins remain tristated until you tell them otherwise.
Driving an output pin high or low while it's shorted to the opposite supply rail will definitely exceed the specifications of the chip, and may blow the pin - but in practice, the chips are fairly resilient to that sort of abuse - the pins don't source or sink all that much more current than they're rated for (not that this is an invitation to do so). Likewise with other dumb things like driving LEDs without the resistor (ie, relying on the internal resistance of the pins to limit the current) - you can get away with things you shouldn't do, and most of the time the chip will survive.
edit - fixed
What is more likely to blow pins is putting too much current through the protection diodes by applying a voltage outside of the supply rails to one of the pins. Applying any voltage to a pin while the chip is not powered counts as exceeding the supply voltage. You must be sure that the current flowing in this case is under 1mA. We definitely see people posting who damaged pins in this way more often than we see people posting who damaged pins by shorting them to ground or supply, and I'm pretty sure that's a lot more common of an error.
DrAzzy:
The bootloader lights up the serial pins, but other than that, all pins remain tristated until you tell them otherwise.
Duh??
The LEDs are connected to the communication chip and not to the main micro; exception might be the boards that can act as HID. The only pin that might be in output state is the TX pin.
DrAzzy:
Driving an input pin high or low while it's shorted to the opposite supply rail will definitely exceed the specifications of the chip, and may blow the pin
The LEDs are connected to the communication chip and not to the main micro;
Sure but the LED on pin 13 is not. The boot loader toggles that one. These days it is actually reset to be an input before the boot loader returns but this was not always the case.
sterretje:
Duh??
The LEDs are connected to the communication chip and not to the main micro; exception might be the boards that can act as HID. The only pin that might be in output state is the TX pin.
Not always, cheap nano clones (the ones with ch340g interface) have tx/rx leds connected to pin 0/1.
The bootloader lights up the serial pins, but other than that, all pins remain tristated until you tell them otherwise.
The bootloader also sets pin 13 as an output to do the initial blinks of the the pin13 LED.
does it actually place all the I/O pins into a high impedance / Hi-Z tri-state condition to protect them, or does it just flip them all into an I/O input state?
The "I/O Input state" is the high impedance tri-state condition...
The bootloader also sets pin 13 as an output to do the initial blinks of the the pin13 LED.
Yes but as I said it puts it back to being an input these days. There was a tie when it didn't.
Test this by running a simple blink program on pin 13 and do not set the pin mode as an output. If it blinks dimly then it is being an input. Put the pin mode command to set it as an output and see the brightness difference. If there is no difference then you have an old boot loader.
Pin 13 connects to the LM358 comparator to drive the L LED on the Uno/Mega, it is not driven from the pin directly.
Other boards may drive it directly via a 1K resistor, requiring about 2.5mA of drive current. Check the schematic of the board you are using.
The point is that Pin13 would not be a good choice for connecting directly to GND or VCC, even if your sketch and the core leave it safely as an HiZ input.
DrAzzy:
What is more likely to blow pins is putting too much current through the protection diodes by applying a voltage outside of the supply rails to one of the pins. Applying any voltage to a pin while the chip is not powered counts as exceeding the supply voltage.
Thanks guys.
DrAzzy
Thank you for the great reply indicating what sounds like a typically robust family of Arduino cards out there.
I hadn't thought much of this additional risk added when using higher external voltages around it, and when the card's Vcc is OFF/ UNPLUGGED and will definitely keep these in mind now .. Thanks Again! JimS
