Pins jam in the Arduino Uno !!!

Projects Programming
1

As a new starter I found three problems with pins numbering for the Arduino Uno :

1- The first header on the board contain pins 0-7, and the second header contain pins 8-13, but the pins in the two headers is a mixture of Digital and PWM together.
2- The page that describe the function analogRead() says:

pin: the number of the analog input pin to read from (0 to 5 on most boards, 0 to 7 on the Mini and Nano, 0 to 15 on the Mega)

, and gives an example of using

int analogPin = 3;
val = analogRead(analogPin);"

, but in pages pinMode() , digitalWrite() , digitalRead() they use the form Ax to use the analog pins

A0-A5

, and so do all the examples !!!

3- If I want to make my sketch portable for the different Arduino boards, I have to know the pin numbers and functions for each board, is there is a place that can tell me so ?

Thanks for all.

2

Al-Zoghby:
3- There is no one place to describe the Uno pins numbering on this site, you have to go to each input or output function page to know pins location to use for each Arduino.

There is this, and more, on the product pages:https://www.arduino.cc/en/Hacking/PinMapping168

But I agree about the analog/digital pin naming. I wouldn't have done it that way.

3

aarg:
There is this, and more, on the product pages:https://www.arduino.cc/en/Hacking/PinMapping168

But I agree about the analog/digital pin naming. I wouldn't have done it that way.

Thank you aarg for your replay
You gave me a link to pin-mapping of the chip, but I want the pin numbers and functions of the boards headers.
It's good to know that you agree about pins mapping.

4

Al-Zoghby:
but I want the pin numbers and functions of the boards headers.

Isn't that what aarg linked to? It shows Atmel ports and pin numbers, Arduino numbers for those pins, and shows their functions, 'digital', 'analogue', 'PWM', 'RX', 'TX', 'Analogue Reference' etc. Also MOSI, MISO, SCK, RESET.

And I like the A0, A1, A2...A5 nomenclature, rather than 0, 1, 2...5. More descriptive. I always use the preceding 'A'.

5

You can have your sketch read the signature bytes of the processor it is running on, see Nick Gammon's page

Scroll most of the way down to "Board type self-detector". Then your sketch can know what hardware is available for use,
6 or 8 analog and 14 digital IO on '328, similar in '32U4 boards, 8 analog and 24 digital IO on 644/1284P type boards, 16 analog and 54 digital on 2560 boards, etc. Lesser amounts on the various Attiny chips, somewhere between 32 & 70 on 2561 chips, perhaps all 83 or 84 or whatever which a fully broken out 2560 based board has, or maybe allow that by default and let the user be responsible for not using pins which are not accessible, same with the 2 analog only inputs on a 328P (A6, A6 only accessible on the SMD packages).

6

CrossRoads:
You can have your sketch read the signature bytes of the processor it is running on, see Nick Gammon's page
Gammon Forum : Electronics : Microprocessors : Sketch to detect Atmega chip types
Scroll most of the way down to "Board type self-detector". Then your sketch can know what hardware is available for use,
6 or 8 analog and 14 digital IO on '328, similar in '32U4 boards, 8 analog and 24 digital IO on 644/1284P type boards, 16 analog and 54 digital on 2560 boards, etc. Lesser amounts on the various Attiny chips, somewhere between 32 & 70 on 2561 chips, perhaps all 83 or 84 or whatever which a fully broken out 2560 based board has, or maybe allow that by default and let the user be responsible for not using pins which are not accessible, same with the 2 analog only inputs on a 328P (A6, A6 only accessible on the SMD packages).

Of course. Duh.
I misunderstood what was wanted.

7

S'alright. Different people read the same thing and interpret it different ways. There was a mix of requests there.
Safest way is using A0-Ax for analog, 0 to x for digital, don't assign any and use Wire.h for I2C; don't assign any and SPI.h for SPI, I don't know if there is a generic ss for the SPI ss pin; and don't assign any and use Serial, Serial1, Serial2, Serial3 for the serial ports.
Any PWM and other special hardware will probably need to be chip specific.

8

OldSteve:
Isn't that what aarg linked to? It shows Atmel ports and pin numbers, Arduino numbers for those pins, and shows their functions, 'digital', 'analogue', 'PWM', 'RX', 'TX', 'Analogue Reference' etc. Also MOSI, MISO, SCK, RESET.

And I like the A0, A1, A2...A5 nomenclature, rather than 0, 1, 2...5. More descriptive. I always use the preceding 'A'.

Dear OldSteve

Forgive me for my English language,

1- aarg linked to a very useful link for the chip pin-out, but I'm asking about the pins in the Uno board headers, they are numbered as:
0,1,2,3,4,5,6,7 and 8,9,10,11,12,13,
but there functions illogically are
RX,Tx,D,PWM,D,PWM,PWM,D AND D,PWM,PWM,PWM,D,D

2- I was wondering about how to number the analog input as 3, while 3 is a PWM pin, so it's logically to number it as A3 not to make conflict with other pins, as published in the analogRead() page.

my best regards.

9

Al-Zoghby:
Dear OldSteve

Forgive me for my English language,

1- aarg linked to a very useful link for the chip pin-out, but I'm asking about the pins in the Uno board headers, they are numbered as:
0,1,2,3,4,5,6,7 and 8,9,10,11,12,13,
but there functions illogically are
RX,Tx,D,PWM,D,PWM,PWM,D AND D,PWM,PWM,PWM,D,D

What's illogical about that? And they're clearly labelled on the board. Or do you want them to look neater RX,TX,D,D,D,D,D,D,PWM,PWM,PWM,PWM,PWM,PWM

2- I was wondering about how to number the analog input as 3, while 3 is a PWM pin, so it's logically to number it as A3 not to make conflict with other pins, as published in the analogRead() page.

I said exactly that in my last post. I prefer to use A0,A1,A2 etc, not 0,1,2 etc
It's a matter of choice with the analogue pins. Both of these are valid:-

val=analogRead(0);
val=analogRead(A0);

Use whichever makes you happy. :slight_smile:

10

CrossRoads:
S'alright. Different people read the same thing and interpret it different ways. There was a mix of requests there.
Safest way is using A0-Ax for analog, 0 to x for digital, don't assign any and use Wire.h for I2C; don't assign any and SPI.h for SPI, I don't know if there is a generic ss for the SPI ss pin; and don't assign any and use Serial, Serial1, Serial2, Serial3 for the serial ports.
Any PWM and other special hardware will probably need to be chip specific.

Dear CrossRoads,

Thank you for your understanding and you professional answer, and I wonder why your answer isn't in the main page to guide beginners like me as in other sites.

My best wishes.

11

analogRead() can (if you want meaningful output) be called with either numbers 0~7 - which will read the corresponding analog pin, OR with A0~A7. Now what are A0~A7? They're just constants - specifically, numbers 14 through 22 - (pin 13 is the highest "digital" pin). This is useful, since you can do digitalRead()/digitalWrite() using the A0~A5 names (pins A6 and A7 on the atmega328p are weird, and can only be used for analogRead - atmel added them as an afterthought, so there's no port/pin register for them).

Internally, analogRead() tests if the argument it's been passed is higher than the last digital pin number, and if it is, subtracts the number of digital pins from the pin number. Otherwise, it uses the number it's passed directly, in the assumption that it's the number of the ADC channel (0~7).

I really would not have done the analog/digital pin mapping like this.

For one thing, we have "analogRead()" to read an analog voltage (makes sense?) and it can be used only on certain pins, which we call "analog pins" (okay, this makes sense too) - but they can also be used as digital pins, despite that this is not discussed in the official docs (much?).... Now then there's also analogWrite() - you might assume that would work on the "analog pins"? Nope, different set of pins. You might assume it would involve an analog voltage? Nope, PWM...

12

DrAzzy:
Now then there's also analogWrite() - you might assume that would work on the "analog pins"? Nope, different set of pins. You might assume it would involve an analog voltage? Nope, PWM...

I agree wholeheartedly on this point. 'pwmOut()', 'pwmWrite()' or similar would have been far more appropriate as a name for the function, and wouldn't give the impression that there's a true DAC onboard.

13

DrAzzy:
analogRead() can (if you want meaningful output) be called with either numbers 0~7 - which will read the corresponding analog pin, OR with A0~A7. Now what are A0~A7? They're just constants - specifically, numbers 14 through 22 - (pin 13 is the highest "digital" pin). This is useful, since you can do digitalRead()/digitalWrite() using the A0~A5 names (pins A6 and A7 on the atmega328p are weird, and can only be used for analogRead - atmel added them as an afterthought, so there's no port/pin register for them).

Internally, analogRead() tests if the argument it's been passed is higher than the last digital pin number, and if it is, subtracts the number of digital pins from the pin number. Otherwise, it uses the number it's passed directly, in the assumption that it's the number of the ADC channel (0~7).

I really would not have done the analog/digital pin mapping like this.

For one thing, we have "analogRead()" to read an analog voltage (makes sense?) and it can be used only on certain pins, which we call "analog pins" (okay, this makes sense too) - but they can also be used as digital pins, despite that this is not discussed in the official docs (much?).... Now then there's also analogWrite() - you might assume that would work on the "analog pins"? Nope, different set of pins. You might assume it would involve an analog voltage? Nope, PWM...

DrAzzy, that's exactly what I want to know about this point, thanks.

14

I had this reaction, too. Probably because I come to arduino from a programming background.

The weird sequence of pins in the arduino probably comes down to the problem of physically laying out components in a chip. I got some insight into this trying to connect a 4*8 array of LEDs to some ribbon cable. Only way to jam the wires in there resulted in a funky sequence of LEDs on the connectors, which I fixed in software.

Truth is - it's even worse than you think. The hardware abstraction layer in the IDE and libraries hides things that are even more specific and irregular: ports and timers and whatnot. Without that abstraction layer, it wouldn't be easy to write code that will run on an arduino without knowing exactly which arduino you are coding to.

It was a good thing to learn, I think, and probably typical of the kinds of things you get when you are working with hardware.

15

I'm still wondering why the pins jammed. :slight_smile: