using integer type to define pins, why?

Projects Programming
1

why do all the examples use variables to define pins? Is this a wast of RAM? isn't it slower than a constant?
My thinking is if you use the later the code wont have to GET the value from ram, guess its a compromise between ram and program memory?

int potpin = 0;  // analog pin used to connect the potentiometer
val = analogRead(potpin);            // reads the value of the potentiometer (value between 0 and 1023)

vs

val = analogRead(0);            // reads the value of the potentiometer (value between 0 and 1023)
2

nixxit:
why do all the examples use variables to define pins? Is this a wast of RAM? isn't it slower than a constant?
My thinking is if you use the later the code wont have to GET the value from ram, guess its a compromise between ram and program memory?

int potpin = 0;  // analog pin used to connect the potentiometer

val = analogRead(potpin);            // reads the value of the potentiometer (value between 0 and 1023)




vs

val = analogRead(0);            // reads the value of the potentiometer (value between 0 and 1023)

The correct way is to use const int:

const int potpin = A0;

This way it doesn't take up any space, but if you ever want to change the pin's assignment, it is easy to change in one location, rather than hunting for all of the 0's in the program. Note, in your example, using pin 0 is wrong, since that is a digital pin. The Arduino environment defines A0..A5 (or A9, etc. depending on the target) so that you don't have to remember that on Uno's the first analog pin is 14, on a Leonardo the first analog pin is 18, and on the Mega it is 54.

Right now, I have 2 different microprocessors (Uno and Teensy 3.0) that I will sometimes want to run the same sketches on, but the pin assignments are different (I have some digisparks also, but I haven't assembled them yet), and I used conditional compilation to switch around the setups.

3

The correct way is to use const int:

Code:
const int potpin = A0;

This way it doesn't take up any space, but if you ever want to change the pin's assignment, it is easy to change in one location, rather than hunting for all of the 0's in the program. Note, in your example, using pin 0 is wrong, since that is a digital pin. The Arduino environment defines A0..A5 (or A9, etc. depending on the target) so that you don't have to remember that on Uno's the first analog pin is 14, on a Leonardo the first analog pin is 18, and on the Mega it is 54.

Are you sure you are not mixing up const with #define statements? A const still takes up space, it just tells the compiler to treat it as a read only value. A #define is just a compile time macro that doesn't take up memory space in the target code. At least that is my take on it?

Lefty

4

nixxit:
why do all the examples use variables to define pins? Is this a wast of RAM? isn't it slower than a constant?
My thinking is if you use the later the code wont have to GET the value from ram, guess its a compromise between ram and program memory?

This comes up often. Using int for pins and other minor issues in the examples are because they were written by humans.

retrolefty:
Are you sure you are not mixing up const with #define statements? A const still takes up space, it just tells the compiler to treat it as a read only value.

As other threads have proven before, this is not always true. avr-gcc will treat a const declarations as a "constant" whenever it can. Variables declared const or with #define end up taking up the same amount of SRAM.

See this thread: http://arduino.cc/forum/index.php/topic,86800.0.html

5

But from the reference:

#define is a useful C component that allows the programmer to give a name to a constant value before the program is compiled. Defined constants in arduino don't take up any program memory space on the chip. The compiler will replace references to these constants with the defined value at compile time.

So there seems to me to be a fundamental difference between a const variable and a #define constant value. The first lives in SRAM forever as a read only value, where the second is not a value stored in SRAM but rather any reference to it's value was fixed at compile time.

Lefty

6 
Note, in your example, using pin 0 is wrong, since that is a digital pin.

you sure ? I pulled that from the Knob example under the servo menu. Im not 100% sure but I think A0 is the first pin on my mega

so should i

const int potpin = A0;
or
#define int potpin = A0;

dose in not really mater?

I thought this had been covered before, im not keen on the way searching works here it returns so many false leads

7

So there seems to me to be a fundamental difference between a const variable and a #define constant value. The first lives in SRAM forever as a read only value, where the second is not a value stored in SRAM but rather any reference to it's value was fixed at compile time.

No, sorry.

Once you put "const" in front the compiler can treat the thing literally as a constant. So any references to it become "load immediate" not "load from memory location x".

8

Ah, so the value will not occupy it's own unique SRAM space? Because the compiler already used it's value any and every where in the program it was referenced?

Lefty

9

Yes. Proof:

const byte myPin = 10;

void setup ()
  {
  digitalWrite (myPin, HIGH);
  }  // end of setup

void loop () { }

Relevant assembler:

00000102 <setup>:
 102:	8a e0       	ldi	r24, 0x0A	; 10
 104:	61 e0       	ldi	r22, 0x01	; 1
 106:	0e 94 86 00 	call	0x10c	; 0x10c <digitalWrite>
 10a:	08 95       	ret

Notice the use of LDI (load immediate) rather than loading from a memory location.

10

If you get rid of the "const" it loads from a memory location:

00000102 <setup>:
 102:	80 91 00 01 	lds	r24, 0x0100
 106:	61 e0       	ldi	r22, 0x01	; 1
 108:	0e 94 87 00 	call	0x10e	; 0x10e <digitalWrite>
 10c:	08 95       	ret

Address 0x0100 in this case.

11

nixxit:
why do all the examples use variables to define pins? Is this a wast of RAM? isn't it slower than a constant?

No and no. Provided it is a const variable.

Some programmers may not put const there, not seeing the point. Without it, what you say is correct.

12

nixxit:
you sure ? I pulled that from the Knob example under the servo menu. Im not 100% sure but I think A0 is the first pin on my mega

When using analog pins is it better to use the Ax pin numbers instead of just "0". This makes the code portable and makes it very clear when reading it what pin you intended to use.

nixxit:
const int potpin = A0;

This is the best method.

13

Just awesome! you guys are very helpful

14

The only additional question I have about pin numbers is why they are int instead of byte type?

Seems a wasted type size and there can be no such thing as a negative pin number, so maybe unsigned int rather then int, but still byte would seem to be more space saving?

Lefty

15

Personally I use byte, because pin numbers are indeed unsigned, and don't go over 255.

16

But does for example analogRead(pin#) function cast it as a int size value inside the function? And as you said a pin number declared as a const anyway doesn't occupy any memory space on it's own, only by the thing that reference it?

Lefty

17

Actually pin numbers, as used with 'digitalWrite(12, HIGH)', are in fact specified as being of type 'uint8_t' so the compiler will down convert the 'int' to an 'uint8_t' for you.

But technically you should be specifying pins as 'const uint8_t pinANALOG = A0' as an example.

18

lloyddean:
Actually pin numbers, as used with 'digitalWrite(12, HIGH)', are in fact specified as being of type 'uint8_t' so the compiler will down convert the 'int' to an 'uint8_t' for you.

But technically you should be specifying pins as 'const uint8_t pinANALOG = A0' as an example.

Ah got it, thank you.

Lefty

19

lloyddean:
But technically you should be specifying pins as 'const uint8_t pinANALOG = A0' as an example.

In other words, "const byte".

20

But of course now I've learned that doesn't save any real space over using const int as applied to pin number use. :smiley:

Lefty