Do I ever need to use "physical pin" numbers in my code?

I see that there is a mapping from "physical pin" numbers to digital/analogue pin numbers in the Arduino; e.g. here for the Uno and here for the Mega 2560. However, all the examples and tutorials I've seen make use of the digital/analogue pin numbers; e.g., the code for the Blink tutorial for the Mega refers to pin number 13 (the digital pin) rather than pin number 26 (the physical pin).

Will I ever need to use these physical pin numbers in my code for either digital or analogue reads and writes?

I am trying to diagnose a problem where my physical Arduino board (a Mega 2560 R3) is behaving very differently to the simulation I set up in SimulIDE and I was wondering whether incorrect pin numbering could be the cause of it. On most of the pins (if not all of them) on the physical board, it seems that the values being read are random, with some non-zero values being returned even when the corresponding sensors are disconnected, and others changing without any corresponding change to the inputs to the physical device.

Not when using the Arduino IDE.

Please post your code and details about the errors you see.

1 Like

So this is not an Arduino issue, is it?

I don't think I've seen references to pin number on the IC, but Arduino pins are known to the hardware as bits in ports A, B, C and D. If you check the pinout for atmega328p (UNO / NANO), what arduino calls pin 13 is known as PB5, that is bit 5 in the port B registers.

The DDRB (Data direction register for port B) controls input/output, while the PORTB register is used to both send output and control pullup, or pulldown for inputs, and finally, PINB register is readonly, to read input on all pins in port B.

1 Like

The whole point of Arduino pin numbers is to hide us, the users, from needing to know about physical pin numbers, ports and port-pins.

The ports and port-pin numbers vary from chip to chip, and even sometimes when the same chip comes in different physical packages, for example atmega328 comes in DIP package with 28 pins and TQFP and VQFN packages with 32 pins.

When you select the "board type", this tells the IDE which port/port-pin/physical-pin corresponds to arduino pin 2 or pin 13, so that you can move your code between boards and chips without having to change the code. All you have to do is connect your led or button or whatever to the pin that's marked 2 or 13 on the board and you don't need to know which port, port-pin etc that actually is on the board you use.

2 Likes

The Arduino framework maps pins on the headers of a board to the ports and bits of the controller on that board. E.g. the Pro Mini board layout can come with various controllers and the unique board pin numbers can be used in code with all those boards.

One problem can not be solved by Arduino pin numbers: the pins can have different alternate functions. If pin 9 on an Uno board supports PWM then pin 9 on another board can have different functionality.

For digital pins and analog inputs the Arduino pin numbers can be used with every board. Analog write (PWM output) should be used with care, because this is an alternate pin functionality not related to fixed Arduino nor controller pin numbers.

1 Like

I think the term "physical pin" is a bit of a misnomer here. If I read it correctly, what you refer to as "physical pins" are pins on the microcontroller, as opposed to pins on the board. Both of these are, strictly speaking, "physical". They just use different numbering schemes, and some of the microcontroller's pins aren't exposed on the board (e. g. PC6 on the Arduino Uno).

If you look carefully on this image https://upload.wikimedia.org/wikipedia/commons/c/c9/Pinout_of_ARDUINO_Board_and_ATMega328PU.svg, you'll realize that for the most part, the board's pins just map 1:1 onto the microcontroller's pins.

And your compiled program doesn't know what "A5" or "PC5" is, anyway - those are just arbitrary labels for the programmer.

1 Like

Thank you all! Those were all very useful replies, as they show that whatever problem I am having, it isn't because I am using the wrong pin numbers.

Cheers.

That's only for the 328P. Take a different processor (Mega, 32U4) and the story is different :wink:

1 Like

In case anyone is interested: I managed to diagnose the cause of my original problem with random values being read even when the pins weren't connected to anything. I was using

pinMode(pin, INPUT);

to prepare my pins (for reading); whereas I should have been using

pinMode(pin, INPUT_PULLUP);

instead. (Explanation is here.)

2 Likes

Reading unconnected pins without pullup or pulldown gives you floating results. That is not a bug. Normally when you read a pin, it is connected to something generating a meaningful value, and you may or may not use pullup or pulldown, to generate default values if the device from time to time disconnects from the pin.

No, but it is an indictment of whatever simulator @ed_graham is using…

The wokwi simulator will return random values on open input pins that are not in INPUT_PULLUP mode.

I suspect that other simulators may not go to the same care.

a7

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.