Not really. Whether the pin is INPUT or OUTPUT matters. Whether the pin is HIGH or LOW matters. Without seeing the two different codes, all we can do is assume that it is perfectly normal.
i just received my arduino mega 2560 r3 and led on pin 13 is always on, even with "bare minimum" sketch.
when i use the blink example it blinks correctly.
have you found any solution to this?
is that the only problem you have or might this be just the tip of the iceberg and the whole board is flawed?
I drug out a selection of Arduinos - a Duemilanove, a Micro, a Mega, a Leonardo, a Due, and an Esplora. I loaded the same sketch onto each one. On the Due, the LED on pin 13 stayed on. On all the others, the LED on pin 13 was off while the sketch was running. Changing the pin from 31 to 13, for each board, caused the onboard LED to flash, as expected.
I guess, then, that JimboZA's suggestion is what you need to do, if having the onboard LED on bothers you.
I just posted and then erased a post saying it's impossible to have what people are seeing with pin 13. But then I got thinking that unlike older arduino boards the current rev3 boards (uno and mega for sure) use an opamp to drive the led, and if the bootloader puts pin 13 back to input mode before jumping to the users sketch (is that the case), then the opamp will be seeing a 'floating input condition', so maybe it's possible for the newer boards to have a 'interrmittent' pin 13 indication? Never occured to me as I don't own any Rev3 boards. Not sure how a LMV358 opamp might respond to a 'floating input pin' condition.
I think this one has been around before. The bootloader flashes the LED and it is probably chance that it is HIGH (although maybe INPUT) when it finishes.
As I said I don't own a Rev3 Uno, but I am running optiboot in an older duem.. board. So I did the following:
Loaded and ran the bare minimum example sketch and when run pin 13 led is off. Removed power and then repowered on with battery, led 13 still off.
Added the below to bare minimum example which should just enable the internal pull-up for pin 13 if the pin
if in input mode, other wise if the pin is left in output mode the output will be 'full on'. When it was run one can see the led on but very very dim.
void setup() {
// put your setup code here, to run once:
digitalWrite(13, HIGH); //enable pin 13 pull_up
}
void loop() {
// put your main code here, to run repeatedly:
}
So my conclusion is that optiboot leaves the bootloader and jumps to the application code with pin 13 in
input mode and the internal pull-up turned off. So I think that leaves optiboot innocent of any random
behaviour of pin13 led being on or off when starting a sketch symptom, if should always be off. So I think it's the newer hardware design using an op-amp section to drive the led that is responsible for any randomly on or off led when the users sketch starts, if that is indeed the true symptom being seen, as the result of the op-amp 'seeing' a floating input pin condition. I suspect even adding a 1 megohm pull-down external resistor to pin 13 would keep the led off in that case.
If this is the case it just further proves the law of "unintended consequences". While the thought of using a op-amp to 'unload' the pin 13 led current burden from pin 13 was a good idea in principal, it appears that it can leave one with random pin 13 behaviour when pin 13 is not being used by the user's sketch.