Go Down

Topic: Curious about pin declare... (Read 1 time) previous topic - next topic

kokpat

I had read a lot of arduino programs/ Textbook, they usually declare the pin by using "int", such as "int ledPin = 11;"

I wonder that using int(-32768 to 32767) to declare pin cost 2 bytes of memory;

but using byte(0 to 255) to declare pin only cost 1 byte of memory.

Why people always using int for declare pin but not byte ?

Thx.

Coding Badly

Why people always using int for declare pin but not byte ?


Don't know.  But the best choice is to attach const...

Quote
[font=Courier New]const int ledPin = 11;[/font]


Then it won't matter what type you use.  (But byte / uint8_t makes your intentions clear.)

UKHeliBob

I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

fungus


Why people always using int for declare pin but not byte ?


Because they're ignorant/careless.

Using plain 'int' also makes the compiler generate slower code because it thinks it's variable. Always use 'const'.

Even better, use an enum, that way the compiler knows even more about how the value will be used (ie. in constant expressions) and you're covered if Atmel makes a chip with more than 255 pins.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

fungus


I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.


If you declare it 'const' the compiler won't put it in RAM (in theory).
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

afremont

Is there something wrong with #define vs. const?  Why waste the storage space?
Experience, it's what you get when you were expecting something else.

Coding Badly

Is there something wrong with #define vs. const?


const carries type information and never interferes with parsing.

Quote
Why waste the storage space?


Why are you concerned about the compiler's storage space?

Coding Badly

I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.


Two bytes of which storage?  Flash?  SRAM?  Both?

Coding Badly

Even better, use an enum, that way the compiler knows even more about how the value will be used (ie. in constant expressions) and you're covered if Atmel makes a chip with more than 255 pins.


enum elements (values) are a good idea but, regardless of the number of elements, the type is always 16 bits.

afremont

#9
May 05, 2013, 12:14 am Last Edit: May 05, 2013, 01:20 am by Coding Badly Reason: 1
Why are you concerned about the compiler's storage space?


I mean RAM.  #define takes no space in RAM, int does.  I don't see the benefit to setting aside 16 bits of RAM to hold the number of a pin and declaring it fixed in value.  Carrying type information by being locked to a single fixed representation at run-time invites hidden promotion of the underlying value which is wasted run-time effort, #define should prevent that and let the compiler figure out the best representation for each reference to the value.  

I'm not concerned at all about the compiler's work space, just my own.  


Moderator edit: over-quote trimmed.
Experience, it's what you get when you were expecting something else.

CrossRoads

I always use byte for assigning pin numbers.
Some say not using
const byte pinX = 4;
could let the sketch accidentally change pinX by accident, I've never had such careless code where that happened.

I had some code with an array pointing to an array kind of thing where #define would not work correctly, but const byte did.
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Coding Badly

I mean RAM.  #define takes no space in RAM, int does.


And const int?

Quote
Carrying type information by being locked to a single fixed representation at run-time invites hidden promotion...


From int to what?

Quote
...#define should prevent that and let the compiler figure out the best representation for each reference to the value.


Why do you believe the compiler does not do the same with const int?

afremont


I mean RAM.  #define takes no space in RAM, int does.


And const int?

Quote
Carrying type information by being locked to a single fixed representation at run-time invites hidden promotion...


From int to what?

Quote
...#define should prevent that and let the compiler figure out the best representation for each reference to the value.


Why do you believe the compiler does not do the same with const int?


A const int is still just an int.  While the compiler "might" optimize away the storage space requirement in RAM or ROM, it has absolutely no obligation to do so.  The compiler is free to completely ignore the qualifier.  Why depend upon something that might not even happen?

By forcing a defined type, you force the (non optimizing) compiler to promote the type here and there when it is used.  People do it all the time by assigning an LED pin to an int when the real type is uint8_t.  Since #define constants are basically typeless, the compiler is free to plug it in anyway it sees fit depending upon the context of the reference.

The answer to your third question is contained within the first answer.  const is just a qualifier, the compiler doesn't have to do anything special just because it's there.  Even attempting to change a const is implementation defined so there's not even a guarantee on how that is handled.
Experience, it's what you get when you were expecting something else.

Coding Badly


So your entire argument is based on a hypothetical C++ compiler that may or may not exist.  Got it.

Given where we are, I will focus my attention on the compiler used to generate code for Arduinos.

afremont

#14
May 05, 2013, 07:20 am Last Edit: May 05, 2013, 07:25 am by afremont Reason: 1


So your entire argument is based on a hypothetical C++ compiler that may or may not exist.  Got it.

Given where we are, I will focus my attention on the compiler used to generate code for Arduinos.



Actually, my entire argument is based upon the ANSI standard definition. Given this is the forum to discuss other microcontrollers and not just the microcosm of Arduino, I think I'll stick with standard C and not what some particular compiler may or may not do with optimizations.
Experience, it's what you get when you were expecting something else.

Go Up