Why use int instead of byte for pin numbers?

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.

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.

1 Like

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

#define led_pin 13

is fine and avoids introducing any variable.

stoopkid:
Why do we use:

int led = 13;

instead of

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.

stoopkid:
Why do we use:

int led = 13;

instead of

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

?

Krupski:

stoopkid:
Why do we use:

int led = 13;

instead of

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:

const byte led = 13;

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

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! :slight_smile:

1 Like

Krupski:

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! :slight_smile:

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

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

Krupski:

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

MarkT:
Also

#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

Osgeld:

MarkT:
Also

#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

const byte X = 4;

and

#define X 4

Osgeld:
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.

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

Wow! A sudden outbreak of 20:20 hindsight.

Except, the hindsight needs a little focus.

Back in 2005, which useful cheap microcontroller families were supported by free, un-hobbled compilers?
Hint: it's a very short list.

I will neither praise nor criticize the many arduino design points (hardware and software, of which some seem valid to me and some silly) being brought up in this post, but rather just celebrate the vast popularity of the arduino platform and the huge membership of this forum, even consisting of some members that think they got it all wrong. :smiley:

If I was to add to the critic list, I would be tempted to add:

Auto-reset circuit that has had many revisions and cannot be defeated with an easy switch or jumper clip selection.

Auto-voltage selection circuit that is complex, forces the priory selection if both voltage sources are available. Should have been a simple jumper clip like an early arduino board had.

Latest rev 3 uno and mega boards that use pin 13 led opamp driver/buffer that has a floating input pin condition allowing the led to randomly be on or off if not forced low by a pin 13 output mode and digital output LOW commands.

Lefty

retrolefty:
I will neither praise nor criticize the many arduino design points (hardware and software, of which some seem valid to me and some silly) being brought up in this post, but rather just celebrate the vast popularity of the arduino platform and the huge membership of this forum, even consisting of some members that think they got it all wrong. :smiley:

It's just like Windows. Just because everyone uses it, doesn't make it good.

majenko:

retrolefty:
I will neither praise nor criticize the many arduino design points (hardware and software, of which some seem valid to me and some silly) being brought up in this post, but rather just celebrate the vast popularity of the arduino platform and the huge membership of this forum, even consisting of some members that think they got it all wrong. :smiley:

It's just like Windows. Just because everyone uses it, doesn't make it good.

Yea, many seem to hate all oil companies but still buy their gasoline. :wink:

Disclaimer, retired oil company employee. Great job, great company, some great supervisors, some piss poor ones also. :smiley:

Lefty

Osgeld:
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

Proof? Constants don't take up RAM.

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

Yes, very good, but the design is good enough that they are selling tens of thousands. The good points are that it is aimed at the beginner market, the shields are a useful add-on, and it was an excellent decision to use the open-source g++ compiler.

Compare that to other boards where you have to buy their own (dodgy) compilers, or get a cut-down "beginner" version, and put up with an IDE that is so complex it's almost impossible to get a project up quickly.

Yeah I figure, maybe they weren't the best programmers or engineers but they did create the best, most successful beginner development board and IDE so there's something to be said about that.