The safest way is to purposefully initialise everything we're going to use.... like variables and pins, arrays etc. Otherwise, we need to make sure we truly know the initial state of the 'particular' board we're using. This probably goes for any kind of system, not just Arduino. True..... pin 13 is the odd-one-out pin, as it's the one that might be connected to the on-board LED (if there is one).
Southpark:
True..... pin 13 is the odd-one-out pin, as it's the one that might be connected to the on-board LED (if there is one).
It isn't just pin 13. pins 0 and 1 also can have issues as they are often connected to external h/w for the USB to serial interface.
And then there can be issues with pin collisions with built in h/w like I2C and SPI.
--- bill
bperrybap:
It isn't just pin 13. pins 0 and 1 also can have issues as they are often connected to external h/w for the USB to serial interface.
And then there can be issues with pin collisions with built in h/w like I2C and SPI.--- bill
Oh geez yeah. I agree. Pin 0 and 1 can be a real pain in the neck (for newbies and those not reading enough tutorials relating to Arduino input/output)!!!! For every arduino tutorial, that (along with other important things) should be one of the first things to write ..... at the very front of the tutorial.
However though, the little symbols that says TX0 and RX0 (next to pins 0 and 1) should draw some kind of attention....... eg. would prompt the inquisitive to ask what it means before using those pins.
But.... on the other hand, you'd think that newcomers are likely to use those pins ....... as many would say....'why not start with using pins 0 and 1?' -- since they're the first couple of pins to use from the low-number end. But then again, I think the arduino tutorials do tell us about which pins to use, and to not use pin 0 and 1 as regular input/output pins.
I avoid using pin 13 for input because of the led circuit but that only matters if there's a led circuit.
bperrybap:
Seems like it might be easier to use a USBasp device along with PeterVH & my version of the USBasp firmware.
If that comment is aimed at me I can assure you that any change from the nice simple system I have would not be "easier" than no change.
Now that I know the cause of the problem I can deal with it fully by including pinMode() commands in my code.
...R
GoForSmoke:
I avoid using pin 13 for input because of the led circuit but that only matters if there's a led circuit.
It can still matter even if there is no led circuit.
If the typical Arduino bootloader is being used it will blink the LED at powerup and reset which might cause issues depending on the h/w attached to it.
For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.
--- bill
bperrybap:
For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.
Indeed.
We must be careful what we attach to pin 13.
...R
bperrybap:
It can still matter even if there is no led circuit.
If the typical Arduino bootloader is being used it will blink the LED at powerup and reset which might cause issues depending on the h/w attached to it.For example, suppose something is hooked up to the LED pin and holds the LED pin low just after power up or low during reset, this would create a short when the bootloader attempts to drive the pin high to blink the LED.
--- bill
I mode my pins though I have trusted the default LOW.
And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
GoForSmoke:
And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
It would have to be OUTPUT LOW to give the symptom that I experienced and which caused me to start this Thread.
...R
GoForSmoke:
I mode my pins though I have trusted the default LOW.And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
The short issue isn't about pin 13 defaulting to given level.
By default when the AVR powers up or is reset all pins are inputs so there never is a problem with any pin at that point in time.
But then time advances and if you are using a bootloader, the bootloader runs which can change things and it does.
The bootloader that is used on AVR based Arduino boards reprograms some of the pins. (LED pin, and serial pins)
And while the bootloader can be built several different ways, it is typically built to blink an LED at powerup and reset.
(behavior is slightly different depending on which bootloader you are using and which version you have but 3 blinks is the norm)
The Arduino boards hook an LED to a pin and the bootloader blinks that LED.
That means that the bootloader changes the pin hooked to the LED from being an input to an output to drive the LED.
It sets it low to turn the LED off, and then sets it high to turn on the LED and back to low to turn off the LED.
So if you have something connected to the pin used to drive the LED (typically pin 13) and that something is driving that pin (low or high; doesn't matter) you will have short when the bootloader runs since the bootloader reprograms the AVR port register from its default powerup/reset state to drive the pin pin and the external h/w is also driving the pin.
Doesn't matter if the external h/w is driving the LED pin high or low, there will be short.
What is disappointing is that the Arduino boys changed the LED circuit on the newer boards and they could have resolved this potential short issue but they didn't.
i.e. they could have made it such the the LED would be off if the pin were an input or low and on if the pin were high or had the pullup turned on.
That way the bootloader could switch the pin from input to input pullup to blink the LED.
While that could still cause issues for external h/w it would never create a short as it would never be making the pin an output.
The current LED circuit, IMO, is worse from a visual point of view than the old circuit.
While it removed the LED load from the pin (which was good), the LED is now on unless the pin is driven low.
So if you have a newer board and make pin 13 an input, the LED is on.
This is different than the old circuit behavior which the LED was off unless the pin was a high output.
The only way to avoid this issue is to rebuild the bootloader to no longer blink an LED, or not to use a bootloader.
IMO, if I was using pin 13 and concerned about it, I'd ditch the bootloader.
ISP programmers are dirt cheap today and supported "out of the box" by the IDE so it isn't like it was 10 years ago where there was not a easy and inexpensive way to program the AVR including using the IDE to program the boards without using a bootloader.
--- bill
bperrybap:
IMO, if I was using pin 13 and concerned about it, I'd ditch the bootloader.
ISP programmers are dirt cheap today and supported "out of the box" by the IDE so it isn't like it was 10 years ago where there was not a easy and inexpensive way to program the AVR including using the IDE to program the boards without using a bootloader.
That is sensible advice but I think there is a piece missing - there is no need to be concerned about using pin 13 if you are satisfied that its usage will not give rise to a short circuit (to GND or to VCC). In the project that gave rise to this Thread there is a large resistor between VCC and pin 13 - so no risk of a short circuit.
It is also worth noting that it is easy to use an Uno as an ISP programmer.
...R
If you're going to use an Arduino board, you need to know about pin 13. BTW you could have saved yourself a lot of typing, I got the part about what the bootloader does the first time around.
In Robin's case there is no led 13 and for some reason I do suspect that Robin got he part about the bootloader first time around too. Maybe it was that Robin post that said so.
It is also worth noting that it is easy to use an Uno as an ISP programmer.
It's a lot easier with Nick's software. In 2012 I went the Arduino site route and ended up having to edit the Uno core file chip ID to get a 328P-PU to work instead of the default 328P-PA.
GoForSmoke:
BTW you could have saved yourself a lot of typing, I got the part about what the bootloader does the first time around.
ok, Perhaps I misinterpreted what you said.
From this comment:
GoForSmoke:
I mode my pins though I have trusted the default LOW.And now I have to watch out for pin 13 defaulting to OUTPUT HIGH?
It didn't sound like you were clear on the difference between AVR default pins states and what the bootloader is doing on that pin.
If you did, my mistake, I was only trying to provide clarity about what happens on pin 13.
--- bill
bperrybap:
With the newer onboard LED circuit used on the newer revision boards, the LED is on whenever the pin is not driven low.
Perhaps I misinterpreted what you said. That would waste about 10mA continually.
GoForSmoke:
Perhaps I misinterpreted what you said. That would waste about 10mA continually.
Not sure I understand what you are saying.
The new boards use an opamp to drive the onboard LED and will light the LED whenever the LED pin is driven high, in input mode, or in input mode with pullup enabled.
i.e. the only way to turn off the LED is to put the LED pin in output mode and set it to LOW so that the LED pin is driven low.
This is why I said if you "fix" the bootloader to set the LED pin back to input mode before the applications is called, the Arduino onboard LED would be on when the application code (sketch) was called and would be on until the sketch set the pin to output mode and set it to LOW.
I have not measured how much current draw is on the LED pin when it is set to low.
--- bill
I like the opamp thing, it only draws when the led is on. 5V through 220 ohms with a 3fV green led gets 9mA and looks bright, but I think that green leds have a lower fV though it depends on the led itself.
INPUT_PULLUP shortcuts what we used to do,
pinMode( pin, INPUT );
digitalWrite( pin, LOW );
You don't need to mode the pin, just set it LOW.
GoForSmoke:
INPUT_PULLUP shortcuts what we used to do,pinMode( pin, INPUT );
digitalWrite( pin, LOW );You don't need to mode the pin, just set it LOW.
Actually if you want the pullup enabled you have to set the bit in the port register not clear it. 
But I want the pin INPUT LOW.
Mode changes the DDR bit except Arduino INPUT_PULLUP also sets the PORT bit HIGH.
But default INPUT LOW wanting, the PORT bit should be LOW.
I will explicitly set both to cover old and new bootloader/board combos (with comments) and not waste time dwelling on it.
GoForSmoke:
But I want the pin INPUT LOW.
What does that mean?
INPUT mode means the pin is an input - neither driven high nor low
But default INPUT LOW wanting, the PORT bit should be LOW.
I will explicitly set both to cover old and new bootloader/board combos (with comments) and not waste time dwelling on it.
Huh?
INPUT LOW doesn't make sense.
If a pin is an input the internal h/w doesn't drive the pin high or low; it is floating unless something externally is attached to the pin and drives it or pulls it one direction or the other.
The AVR Arduino code for pinMode() sets the DDR register bit to 1 and the PORT register bit to zero.
So this doesn't make sense:
pinMode( pin, INPUT );
digitalWrite( pin, LOW );
since the pinMode() already sets the PORT register bit to 0
The additional digitalWrite() doesn't change anything.
--- bill
bperrybap:
What does that mean?INPUT mode means the pin is an input - neither driven high nor low
Huh?
INPUT LOW doesn't make sense.
If a pin is an input the internal h/w doesn't drive the pin high or low; it is floating unless something externally is attached to the pin and drives it or pulls it one direction or the other.
YES IT DOES. That is the difference between mode INPUT and write HIGH or LOW, pinMode( pin, INPUT_PULLUP ) sets the pin DDRx LOW and the pin PORTx HIGH while pinMode( pin, INPUT ) only changes the pin DDRx.
YOU KNOW THIS > QUIT TROLLING. I use this in direct port manipulation, it's how the HW works.