Pages: [1] 2 3   Go Down
Author Topic: Why use int instead of byte for pin numbers?  (Read 3127 times)
0 Members and 1 Guest are viewing this topic.
California
Offline Offline
Sr. Member
****
Karma: 3
Posts: 433
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Why do we use:
Code:
int led = 13;
instead of
Code:
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.
Logged

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I always use byte for values less than 255
Logged


California
Offline Offline
Sr. Member
****
Karma: 3
Posts: 433
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Global Moderator
Boston area, metrowest
Online Online
Brattain Member
*****
Karma: 524
Posts: 26422
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

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.

0
Offline Offline
Shannon Member
****
Karma: 200
Posts: 11690
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
#define led_pin 13
is fine and avoids introducing any variable.
Logged

[ I won't respond to messages, use the forum please ]

UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Why do we use:
Code:
int led = 13;
instead of
Code:
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.
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Worst state in America
Offline Offline
God Member
*****
Karma: 32
Posts: 792
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Why do we use:
Code:
int led = 13;
instead of
Code:
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 ?
Logged

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Why do we use:
Code:
int led = 13;
instead of
Code:
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:
const byte led = 13;
Then the compiler knows that it's a byte type and tells you if you do something stupid with it.
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Worst state in America
Offline Offline
God Member
*****
Karma: 32
Posts: 792
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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!  smiley
Logged

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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!  smiley
... 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 smiley-wink

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 smiley-wink
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Worst state in America
Offline Offline
God Member
*****
Karma: 32
Posts: 792
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


... 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 smiley-wink

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 smiley-wink

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?
Logged

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


... 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 smiley-wink

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 smiley-wink

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 smiley-wink  But that's the cynic in me getting out again.  Wait a minute, I *am* the cynic in me!!!!
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Also
Code:
#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
Logged


UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Also
Code:
#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:
const byte X = 4;
and
Code:
#define X 4
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Worst state in America
Offline Offline
God Member
*****
Karma: 32
Posts: 792
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Pages: [1] 2 3   Go Up
Jump to: