There are several different types in the Arduino programming language. They each have different applications that can use up the limited RAM in the Arduino. When should i use each?

  • 2
    Could just be me, but this doesn't seem on-topic. I mean, it's basically an SO question. Maybe a topic for a Arduino Meta question? – hichris123 Feb 14 '14 at 3:26
  • 3
    While I'm inclined to agree that this isn't entirely on-topic, I suppose it's worth noting that the types available using the Arduino IDE aren't exactly the same as regular C++. Notably, the type names boolean, byte and word. are not standard C++. Additionally, the String class is nothing like the C++ std::string. Perhaps a more specific question about the differences is warranted? – Peter Bloomfield Feb 14 '14 at 11:50
  • 2
    I think this question has value as these are not standard types. Explaining how the map from Arduino to avr-gcc is important. – Cybergibbons Feb 14 '14 at 13:20
  • First of all, arduino programmers may not want to go to SO to get their questions answered. second of all, The Arduino has very limited ram, so variable choice based on variable size is important. – TheDoctor Feb 14 '14 at 14:01
  • 1
    The question was in context of specific usage and differences from that when used in Arduino. – mpflaga Feb 14 '14 at 15:50

One should appreciate that the Arduino is an Embedded Processor. Specifically that it has limited resources of RAM and ROM(aka Flash/program space).

Often is the case I see coding use the "int" defaultly. Almost sloppily. If that works great.

BUT!!!! You can run out of room REAL FAST with only 2K of RAM.

I would recommend that you size down your type to the minimum of what it needs to be describing it. One also gets a better understanding of what it really is and its limitations. There is no need for an array of int(16bits) from bytes that were recieved from the SPI, UART or I2C. Or a matrix of RGB's that consume 3 bytes each, being int's. You cut your capacity in half.

The pro/con: PRO: using default int everywhere makes it more inter changeable. The CON is that such interchangeability can lead to unintentional casting errors.

I would also recommend using C99 type def's which can be found at "avr_stdint.html">http://www.nongnu.org/avr-libc/user-manual/group_avr_stdint.html" and elsewhere. It makes things vivid, regards to this aspect. Hence a "int" would be a "int16_t", "unsigned long" be "uint32_t" etc...

It is worth knowing that in some cases a byte or char can not be replaced with int8_t, as such when used with string array functions. But they are still just as vivid.

  • Or you could use the mega with 128x the ram :) – TheDoctor Feb 14 '14 at 4:11
  • @TheDoctor - the mega only has 4X the ram. 2K vs 8K – Connor Wolf Feb 17 '14 at 3:52
  • @FakeName - sorry, that's 256kb flash – TheDoctor Feb 17 '14 at 4:07
  • @TheDoctor - That's still only 8X. 32K vs 256K. – Connor Wolf Feb 17 '14 at 4:17

An overview of the most commonly used variables:

  • byte: uses one byte (8 bits), holds numbers from 0 to 255
  • char: a signed byte
  • boolean: uses 1 byte, but only holds a value of true or false
  • int: uses 2 bytes, holds numbers from -32768 to 32767, mostly used in general programming. an int is what is known as a signed variable, where the last bit controls if it is negative or positive
  • long: uses 4 bytes, holds numbers from -2147483647 to 217283648, it is also signed
  • long long: uses 8 bytes, can hold -9223372036854775808 to 9223372036854775807, signed
  • float: uses 4 bytes, holds decimals from -3.4028235E+38 to 3.4028235E+38.
  • double: almost identical to float
  • string: an array of chars that represent text
  • String: not to be confused with string, this is a class that holds text data with extra functions

Most variable declarations can be prefixed with signed or unsigned to change the function of the sigh bit. For example, unsigned int x = 0; would create a variable that holds numbers from 0 to 65535 because the sign bit is used as an extra data bit.

  • This makes some extremely broad assumptions, and does not list their caveats. All the variable sizes are not specified, can vayry on some platforms/compilers, and is compiler implementation dependent. Furthermore, you're grossly oversimplifying things like floats, which have a large range, but limited resolution. – Connor Wolf Feb 17 '14 at 3:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.