When to byte the int (bit budgeting)

Hey all, I am working on a project which is quickly running out of space. So, I am now going back through and doing come closer examination of my code and how to make it a little more efficient. My question is this... In nearly learning example given ints are called for nearly everything. Ex. int ledPin = 1; or int myVal = 1; Is it bad fu to use byte for pins as we never get above the number 13? if myVal was only 50, I would have lots of head room if I used a byte instead of an int. More so, if I am wanting to store the value of a yes or no question, I could use a boolean and only use 1 bit. But I see lots of examples where folks tie the value to an int. So, where is (or is there) right or wrong?(or worse... bad form 8-)).

Also relating to bytes (and it may be the answer to the question above) When I switched out some bytes with ints and watched it in the terminal (serial read) bytes only show up as little square boxes not a value. Now, it seems to operate just fine, it just is unusable if I needed to troubleshoot.

Lastly, how does Arduino see arrays? I have a lot of stuff I am pulling from PROGMEM via arrays. to be honest it is my first time playing with them. If I have an array with 6 pointers, where does that live (what type of memory?). As I read it PROGMEM is used to keep RAM clear as it is not bogged down with bunches of strings. But, it would seem that the arrays would be eating some RAM. So, perhaps I am over analyzing this, but am just curious.

What kind of space are you running out of, program memory (Flash) or data memory (RAM)?

bytes only show up as little square boxes not a value

I think that's because they get sent as an ASCII code, without being converted to decimal. Try:

serial.print (my_byte_variable, DEC);

I have made this proposal elsewhere, but I'll say again that I do not think that printing a byte/uint8_t should be the same operation as printing a char. I think people (mostly) use chars to represent character data, and (mostly) use byte/uint8_t as small integers. This is especially true in memory constrained environments, in cases like this for example, where the programmer is simply trying to conserve space by using the single-byte integral types. But many people convert to byte only to be bitten (sorry! :)) by the "small box syndrome".

byte pin_number = 6;
Serial.print(pin_number);

should print "6" in my opinion, and not a box.

Mikal

Hey Anachrocomputer, Thanks a lot. The DEC did the trick for the Serial.read. Sorry it took so long to try, it has been a little nutty around here.

I am currently sitting at about 8k in flash and am still in the process of building the menu, so there more bulk to come. I just see my number increasing steadily so I thought I would start being economical now so I do not have to go back and replace a bunch of stuff. As to RAM, I am trying to use only a limited number of variables that will get filled by values stored in EEPROM. This way the end user doesn't have to keep re entering the settings, and I don't have to keep up with a gagillion globals. Based on which sequence is running, only those values are called and manipulated. So, I can not give an exact number, but I believe it to be low. But this is why I was also asking about the arrays. I do not know what they cost. I know that my over all size and RAM usage will go down substantially as I remove (or comment out) all my serial calls. But being that I am still trying to get up to speed in micros, I am trying to learn good habits. I am nearly finished with a VB project I am updating from about 3 years ago. I am fixing and cleaning all the mistakes that I made, forcing things to work. I don't necessarily want to do that here. :)

mikalhart, I agree, but the DEC solution worked and was not a terrible mod to make.

A “trick” to save RAM is turn your variable definitions with constants into #define’s.

So…

int ledPin = 1;

Becomes

#define ledPin 1

Then the compiler takes care of replacing every instance of ledPin with 1. Another way to acheive the same results is:

const int ledPin = 1;

And yes, I use “byte” for all my pin definitions as a general rule (and another place I can like small loop counters, etc.). It’s an ingrained habit from the old days of programming mainframes supporting 100 concurrent users with only 64K of memory. I even think the included examples should be changed to not encourage this bad behavior of using variables for constants! The first program new Arduino users see is Blink with its evil “int ledPin = 13;”! :wink:

As mentioned in another thread recently, it’s a good practice to use all-capital names for macros (#define symbols), and not for other stuff. That way, the compiler won’t accidentally expand your macro where it shouldn’t be expanded. It’s easier than you think to accidentally pick the same name that somebody else needs to use.

#define txBuffer 8
byte buffer[txBuffer];

#include <Wire.h>

[glow]error: Wire.h: constant not expected:  '8'[/glow]
#define TX_BUFFER_SIZE 8
byte buffer[TX_BUFFER_SIZE];

#include <Wire.h>

it's a good practice to use all-capital names for macros (#define symbols), and not for other stuff. That way, the compiler won't accidentally expand your macro where it shouldn't be expanded.

Good advice.

Personally I use "const" for my constants and leave the #define's for compiler directives.

I actually just read about using const instead of # defines just 2 or 3 nights ago and have since changed many things to the const. This is the danger of learning by search. I have been reading through the extended reference, then searching the forum to find the proper semantics so I could use it in context. I have learned most of what I know so far this way. When I searched the # define, I found endless sketches with gobs of # defines at the head. So, I thought this was the way to do things. Lemming syndrome. Upon re-reading the #define section, I saw the reference to the "const" being preffered rather shortly into the page. Doh! I remember when I first started playing with the arduinos, that even though I had some previous programing (VB) experience, arduino code was totally Greek. Now that I am starting to get a little comfort in Arduinoeese, I am starting to try my hand at true AVR, and feel as if I am starting all over again. Fortunatly, there are a number of concepts and terminology used in the Arduino IDE that come from c, so there are at least 4 words I know. ;) Live and learn eh'.

Oh yeah, back over to the topic...(sorry, I got side tracked) Any idea about how the arrays are calculated?

Hey halley, you said "use all-capital names for macros (#define symbols)," Sorry, coming from the vb world, macros are completely different. Am I reading your wording to say a (symbols/macros) are the same as thing as constants? I have seen symbols in action scripting with Flash but I have not seen it here.

I actually just read about using const instead of # defines just 2 or 3 nights ago and have since changed many things to the const. This is the danger of learning by search. I have been reading through the extended reference, then searching the forum to find the proper semantics so I could use it in context. I have learned most of what I know so far this way. When I searched the # define, I found endless sketches with gobs of # defines at the head. So, I thought this was the way to do things. Lemming syndrome. Upon re-reading the #define section, I saw the reference to the "const" being preffered rather shortly into the page. Doh! I remember when I first started playing with the arduinos, that even though I had some previous programing (VB) experience, arduino code was totally Greek. Now that I am starting to get a little comfort in Arduinoeese, I am starting to try my hand at true AVR, and feel as if I am starting all over again. Fortunatly, there are a number of concepts and terminology used in the Arduino IDE that come from c, so there are at least 4 words I know. ;) Live and learn eh'.

Personally I still use defines for all the global scope constant values. It just seems more "right" to me. A const is still technically a variable and should be stored as such. I'd hope that the compiler is smart enough to optimize that away though. If it does then the two are equivalent. If it does not then using const wastes RAM for no good reason. To me things which are done with # define were never variables and shouldn't look like variables and so I do not use const. But, it's really a personal choice.

MYX, every language calls things by different names.

In C and C++, the #define statement is a preprocessor directive that defines a macro. The macro may have untyped arguments in a parenthetical list, or not. Once defined, a macro is simply expanded in-place wherever the preprocessor detects it in the future. The preprocessor is not looking at variables, types, functions, or anything semantic at all... it just glues strings together like a search-and-replace function in your editor. The compiler runs after the preprocessor, with the final version of the code all expanded out, and starts checking for keywords like const or typedef, or types like int or char, or variable names or function names.

Traditional C programmers (like me) use #define to give names to constants in a program and to define text-substitution macros. The only difference is that a #defined macro can take arguments, whereas a #defined constant does not. For example, integer and floating-point constants, enclosed in brackets to avoid getting bitten by unexpected trouble when expanded:

#define MAXLINE   (256)  /* maximum number of characters per line */

#define FUDGE_FACTOR  (2.5)

Macros, again with extra brackets:

#define TWICE(x)  ((x) * 2.0)

#define MAX_VAL(a, b)  ((a) > (b) ? (a): (b))

But now that we have the "new" ANSI syntax for 'const int' and so on, we can dispense with the use of #define for constants and just use it for macros. Bue we will probably go on informally calling anything done with #define a "macro", even when it has no parameters.

Using 'const', those first two examples would be:

const int MAXLINE = 256;

const double FUDGE_FACTOR = 2.5;

I just had to link this thread: (Reforming Datatype Practices) http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1227053665/0

I always use a typedef in my sketches. [I teach arduino to some friends and they found static const a bit strange]

typedef constant (static const);

constant byte ledPin = 13;