Go Down

Topic: Why use int instead of byte for pin numbers? (Read 4191 times) previous topic - next topic

Why do we use:
Code: [Select]
int led = 13;
instead of
Code: [Select]
byte led = 13;

If you would never need to define more than 256 pins, why use the extra space for int? Is there a reason?

Thanks.

Osgeld

I always use byte for values less than 255
http://arduino.cc/forum/index.php?action=unread;boards=2,3,4,5,67,6,7,8,9,10,11,66,12,13,15,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,86,87,89,1;ALL

I'm thinking that's the best idea unless there is something I'm missing. Which is likely.

It's just that's the way it's done in most examples, even the arduino default ones. So I figured there may be a reason.

CrossRoads

I always use byte, not int.

sometimes even
const byte  ledPin = 13;

but generally not, because I don't allow ledPin to change value in the software.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

MarkT

People often use int to avoid having to explain more datatypes - byte takes less space and
is perfectly reasonable.  const declarations allow the compiler to optimize the variable away
with luck. Also
Code: [Select]

#define led_pin 13

is fine and avoids introducing any variable.
[ I won't respond to messages, use the forum please ]

majenko


Why do we use:
Code: [Select]
int led = 13;
instead of
Code: [Select]
byte led = 13;

If you would never need to define more than 256 pins, why use the extra space for int? Is there a reason?

Thanks.

The answer is simple:  The Arduino programmers are lazy and don't have much of a clue.  The whole of the core is riddled with wrong data types, bad practices, and generally stupid ways of doing things.  All of which end up rubbing off on users who are new to programming and blindly copy how Arduino have done things, picking up said bad habits and practices for themselves.

Krupski


Why do we use:
Code: [Select]
int led = 13;
instead of
Code: [Select]
byte led = 13;

If you would never need to define more than 256 pins, why use the extra space for int? Is there a reason?

Thanks.


A "byte" type is the same as "uint8_t" (uses one byte of memory).  An "int" is an unsigned 16 bit variable (uses two bytes of memory).

For constants like "led = 13", why not just use #define led 13 ?
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

majenko



Why do we use:
Code: [Select]
int led = 13;
instead of
Code: [Select]
byte led = 13;

If you would never need to define more than 256 pins, why use the extra space for int? Is there a reason?

Thanks.


A "byte" type is the same as "uint8_t" (uses one byte of memory).  An "int" is an unsigned 16 bit variable (uses two bytes of memory).

For constants like "led = 13", why not just use #define led 13 ?

Because that isn't strongly typed.  Better to use:
Code: [Select]

const byte led = 13;

Then the compiler knows that it's a byte type and tells you if you do something stupid with it.

Krupski


The answer is simple:  The Arduino programmers are lazy and don't have much of a clue.  The whole of the core is riddled with wrong data types, bad practices, and generally stupid ways of doing things.  All of which end up rubbing off on users who are new to programming and blindly copy how Arduino have done things, picking up said bad habits and practices for themselves.


Well now that we are dissing Arduino, allow me to add my gripes!

The HARDWARE design is all wrong. Ever try to use the "mounting" holes on the board? Impossible. They are too close to connectors, and there are no "keep-outs" to protect traces from screw heads or standoffs.

There are not enough VCC and GND points available for prototyping.

There is no good place to clip on a ground wire (like for a scope probe).

There is not enough keep-out clearance around the ICSP connector for the MEGA16 USB processor, and BARELY enough room around the main ICSP connector.

The USB interface uses a 16.000 crystal, but the CPU uses a lousy resonator that drifts with temperature.

Don't believe this one? Setup a 60 Hz square wave (or 50 depending on where you live), watch it on your scope with the scope sync'd to the line and watch it's drift.

Then touch the resonator and you will see the frequency slowly change (drift rate changes) as it warms up.

It's not finger capacitance - the change doesn't happen immediately, it SLOWLY drifts! Remove the finger and it drifts back down.

Wonderful design where PRECISION TIMING is needed (not).

The connectors on the board should have been MALE pins, not a female header. It's much easier to make a custom female-to-female cable with Sparkfun or Pololu jumper wires and single row or dual row connectors.

Because of this, the first thing I usually do is de-solder the connectors on an Arduino and replace them with male header pins.

Voltage regulator: Why not use something more beefy like a 7805 and some decent heat sinking (or at least provide a spot to solder in an optional one)?

Pin numbers: How stupid is that? What's wrong with "PORTB, BIT 7"?

Software gripes:

Why is map() done with long ints? It's almost useless that way. I modified my library (overloaded the function) to also support floats.

Speaking of floats, why doesn't the IDE have the option to enable or disable floating point support for printf, sprintf, sscanf, etc? I had to write my own mod to add that feature!

[rant off}

Gosh I feel so much better now!  :)
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

majenko



The answer is simple:  The Arduino programmers are lazy and don't have much of a clue.  The whole of the core is riddled with wrong data types, bad practices, and generally stupid ways of doing things.  All of which end up rubbing off on users who are new to programming and blindly copy how Arduino have done things, picking up said bad habits and practices for themselves.


Well now that we are dissing Arduino, allow me to add my gripes!

The HARDWARE design is all wrong. Ever try to use the "mounting" holes on the board? Impossible. They are too close to connectors, and there are no "keep-outs" to protect traces from screw heads or standoffs.

There are not enough VCC and GND points available for prototyping.

There is no good place to clip on a ground wire (like for a scope probe).

There is not enough keep-out clearance around the ICSP connector for the MEGA16 USB processor, and BARELY enough room around the main ICSP connector.

The USB interface uses a 16.000 crystal, but the CPU uses a lousy resonator that drifts with temperature.

Don't believe this one? Setup a 60 Hz square wave (or 50 depending on where you live), watch it on your scope with the scope sync'd to the line and watch it's drift.

Then touch the resonator and you will see the frequency slowly change (drift rate changes) as it warms up.

It's not finger capacitance - the change doesn't happen immediately, it SLOWLY drifts! Remove the finger and it drifts back down.

Wonderful design where PRECISION TIMING is needed (not).

The connectors on the board should have been MALE pins, not a female header. It's much easier to make a custom female-to-female cable with Sparkfun or Pololu jumper wires and single row or dual row connectors.

Because of this, the first thing I usually do is de-solder the connectors on an Arduino and replace them with male header pins.

Voltage regulator: Why not use something more beefy like a 7805 and some decent heat sinking (or at least provide a spot to solder in an optional one)?

Pin numbers: How stupid is that? What's wrong with "PORTB, BIT 7"?

Software gripes:

Why is map() done with long ints? It's almost useless that way. I modified my library (overloaded the function) to also support floats.

Speaking of floats, why doesn't the IDE have the option to enable or disable floating point support for printf, sprintf, sscanf, etc? I had to write my own mod to add that feature!

{rant off}

Gosh I feel so much better now!  :)

... and you're barely scratching the surface ...

You forgot to mention the 160 mil spacing of the digital headers - makes it almost impossible to use perfboard / stripboard for prototyping.

And why cripple it with an Atmel chip anyway?  That was a bad idea from the outset ;)

Another nice option would have been a jumper to select the chip's Vcc - set it to 3.3v if you want to use 3.3v peripherals - saves all that faffing around with level shifters or butchering you board to make it 3.3v.

And why the hell did they use a full size USB socket?  Those things are useless - On one of my UNO boards I have to hold the cable in the right position to be able to program it, and the sockets get in the way of any through-hole components on the shield above.  I have little foam pads stuck to my sockets.  Mini B sockets (like everyone else in the industry uses) would have been just a bit better ;)

Krupski



... and you're barely scratching the surface ...

You forgot to mention the 160 mil spacing of the digital headers - makes it almost impossible to use perfboard / stripboard for prototyping.

And why cripple it with an Atmel chip anyway?  That was a bad idea from the outset ;)

Another nice option would have been a jumper to select the chip's Vcc - set it to 3.3v if you want to use 3.3v peripherals - saves all that faffing around with level shifters or butchering you board to make it 3.3v.

And why the hell did they use a full size USB socket?  Those things are useless - On one of my UNO boards I have to hold the cable in the right position to be able to program it, and the sockets get in the way of any through-hole components on the shield above.  I have little foam pads stuck to my sockets.  Mini B sockets (like everyone else in the industry uses) would have been just a bit better ;)


Gee... I have to agree with everything you said. I forgot about that goofy pin spacing problem. I wonder if it was a mistake in the initial design that had to be carried through for "compatibility" or if it's intentional so that specially spaced "shields" (i.e. something they can sell) have to be used instead of plain old perfboard?
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

majenko




... and you're barely scratching the surface ...

You forgot to mention the 160 mil spacing of the digital headers - makes it almost impossible to use perfboard / stripboard for prototyping.

And why cripple it with an Atmel chip anyway?  That was a bad idea from the outset ;)

Another nice option would have been a jumper to select the chip's Vcc - set it to 3.3v if you want to use 3.3v peripherals - saves all that faffing around with level shifters or butchering you board to make it 3.3v.

And why the hell did they use a full size USB socket?  Those things are useless - On one of my UNO boards I have to hold the cable in the right position to be able to program it, and the sockets get in the way of any through-hole components on the shield above.  I have little foam pads stuck to my sockets.  Mini B sockets (like everyone else in the industry uses) would have been just a bit better ;)


Gee... I have to agree with everything you said. I forgot about that goofy pin spacing problem. I wonder if it was a mistake in the initial design that had to be carried through for "compatibility" or if it's intentional so that specially spaced "shields" (i.e. something they can sell) have to be used instead of plain old perfboard?

My guess is the latter ;)  But that's the cynic in me getting out again.  Wait a minute, I *am* the cynic in me!!!!

Osgeld


Also
Code: [Select]

#define led_pin 13

is fine and avoids introducing any variable.


yea, I am getting close to the edge of ram in one of my project, changed all my const X's to #defines and freed up almost 2 dozen bytes of ram
http://arduino.cc/forum/index.php?action=unread;boards=2,3,4,5,67,6,7,8,9,10,11,66,12,13,15,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,86,87,89,1;ALL

majenko



Also
Code: [Select]

#define led_pin 13

is fine and avoids introducing any variable.


yea, I am getting close to the edge of ram in one of my project, changed all my const X's to #defines and freed up almost 2 dozen bytes of ram

Surprising that, since const variables are stored in progmem, not in RAM...

Once it has gone through the compiler there is no difference between
Code: [Select]

const byte X = 4;

and
Code: [Select]

#define X 4

Krupski


yea, I am getting close to the edge of ram in one of my project, changed all my const X's to #defines and freed up almost 2 dozen bytes of ram


If you are running out of ram, it may be in part due to not having constants in PROGMEM.

For example, if you do this:

Serial.print("Sensor control - Main Menu");

that string is copied into SRAM and wastes it. If you do this instead:

Serial.print(F("Sensor control - Main Menu"));

or this:

Serial.print_P(PSTR("Sensor control - Main Menu"));

the string will be copied from program memory directly to the output and not use any SRAM.

Another way to save SRAM is to use MALLOC() and FREE() to dynamically allocate and de-allocate buffers on the fly, rather than having several defined all the time. Or, use one common buffer among all functions that need it.

I'll bet though you will gain the most savings by moving all your constants into PROGMEM where possible.

Hope this helps.
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Go Up