A/D nominal port interaction

Hi all, I'm 100% sure this has been addressed somewhere but I've done some digging and can't find it. Please point if you know where to look.

I was putting together this little demo for a workshop and couldn't figure out why the LED on D5 was coming up dim; meter tested it at only 2.4v out of the pin. Changed out every component involved, including the board, before figuring out that my input pin was A5. Switched it to A0 and problem solved.

However, I'm dead curious what's happening here and how that can be avoided (if, say, I wanted to use all digital pins 0-13).

pinMode assignments are basic output/input format; no internal pullups are active.

You can see in the video that the third LED from the right just lacks the gleam the others are sporting.

Here's the setup.

If the problem is not hardware, then it must be software.

Have you tried swapping the dim LED with another?
If the LED which you have moved to another place it still dim then it is a faulty LED.
If not then check the resistor value is actually the same as all the rest, if it is then look at the pin mode setup for that LED.

Otherwise post your code.

@wallup Installation and Troubleshooting is for Problems with the Arduino itself NOT your project. It says so in the description of the section. Therefore I have moved your post here.

You may want to read this before you proceed:-
how to get the best out of this forum

That's NOT normal so it would SEEM that your Arduino is bad. But it's very unusual for one pin to go partially-bad.

You might try a simple test program where you just write HIGH to pin 5. Or, modify the Blink Example to use Pin 5 and with a longer delay so your meter has time to measure the voltage. And check it with nothing else connected to pin 5, just the meter.

I have found that with the Uno, Mega and RPi3B+, when I put an LED onto a unprogrammed pin, wonkies can happen; such as dimly lit LED's.

On an Uno A4 and A5, if I remember correctly, serves as I2C pins and one of those pins would be a clock, which would toggle the LED at about 1/2 brightness with a 50% duty cycle.

Those are my guesses.

Ok thanks everyone. (Mike sorry to make you do house keeping: I was approaching this question as "how does Arduino manage pin assignments" rather than troubleshooting my project). Turns out that I had a leftover pinMode input assignment, after switching from a button on D2 to the pot on A5. So I was confusing D5 by assigning it twice? Dropped the Input assignment for the analog pin and it's fine.

I'm still very curious to better understand what's happening in the board when assigning pinmodes, why an analog read pin doesn't require it, and what's happening in D5 when it's been (accidentally) set as an input but then gets an output command. I'll keep digging on my own but if anyone can suggest a resource to read about that I'd appreciate it.

Here's the (very simple) code:

int led3 = 3;
int led4 = 4;
int led5 = 5;
int led6 = 6;
int led7 = 7;
int led8 = 8;
int led9 = 9;
int led10 = 10;
int led11 =11;
int led12 = 12;
int led13 = 13;

int potIn = 5;

int val = 0;

int setspeed = 0;
void setup()
{
pinMode(led3, OUTPUT);
pinMode(led4, OUTPUT);
pinMode(led5, OUTPUT);
pinMode(led6, OUTPUT);
pinMode(led7, OUTPUT);
pinMode(led8, OUTPUT);
pinMode(led9, OUTPUT);
pinMode(led10, OUTPUT);
pinMode(led11, OUTPUT);
pinMode(led12, OUTPUT);
pinMode(led13, OUTPUT);
pinMode(potIn, INPUT); //Removed, fixed problem

Serial.begin(9600);
}

void loop()
{
val = analogRead(potIn);

setspeed = map(val, 0, 1023, 6, 225);
Serial.print(val);
Serial.print("::");
Serial.print(setspeed);
Serial.println();

digitalWrite(led3, HIGH);
delay(setspeed);
digitalWrite(led4, HIGH);
delay(setspeed);
digitalWrite(led5, HIGH);
delay(setspeed);
digitalWrite(led3, LOW);
delay(setspeed);
digitalWrite(led6, HIGH);
delay(setspeed);
digitalWrite(led4, LOW);
delay(setspeed);
digitalWrite(led7, HIGH);
delay(setspeed);
digitalWrite(led5, LOW);

delay(setspeed);
digitalWrite(led8, HIGH);
delay(setspeed);
digitalWrite(led6, LOW);

delay(setspeed);
digitalWrite(led9, HIGH);
delay(setspeed);
digitalWrite(led7, LOW);

delay(setspeed);
digitalWrite(led10, HIGH);
delay(setspeed);
digitalWrite(led8, LOW);

delay(setspeed);
digitalWrite(led11, HIGH);
delay(setspeed);
digitalWrite(led9, LOW);

delay(setspeed);
digitalWrite(led12, HIGH);
delay(setspeed);
digitalWrite(led10, LOW);

delay(setspeed);
digitalWrite(led13, HIGH);
delay(setspeed);
digitalWrite(led11, LOW);

delay(setspeed);
digitalWrite(led12, LOW);
delay(setspeed);
digitalWrite(led13, LOW);
delay(setspeed);
}

ding ding ding -- unnecessary analog pinmode assignment

Because when you call the analogRead function the code makes sure that it is routed as an analogue input, this overrides anything you have previously set on that pin, with the exception of the INPUT_PULLUP call.

It is setting the registers that define the switches on the input pin connecting it to other circuitry in the processor.

It can enable or disable the input pull up resistor. In fact that was the way you enabled the pull up resistor, by defining a pin as an input and the writing high to it. It got changed about 12 years ago to make it less confusing to people.

I remember being one of the confused ones writing high to an input pin back then...

Thanks for this mini lesson -- I really do appreciate it.

Marginally. :roll_eyes: