**Random thoughts about bits & bytes...**

**- You can do a LOT of programming without worrying about bits & bytes.** It's important to know that a signed integer can hold values between about +/- 32,000, (decimal) etc. And, if you don't remember the exact limits you can always look it up. Sometimes it's handy to know that a type int is 16-bits (etc.) but most of the time you only need to know the decimal size limits or any particular variable type (and if it's floating-point or integer and if its signed or unsigned).

**- If you are programming an microcontroller or writing a driver where you are "close to the hardware", you often DO need to understand bits & bytes.** But with the Arduino programming language, you can write a "bit" to an output pin (high or low, 1 or zero) or read a bit from an input pin without even thinking about it as a bit.

**-** The Windows Calculator in *Programmer View* can convert between decimal, binary, hexadecimal, and octal. (Octal is rarely used.)

**-** When we are using bits, we are usually *thinking* of a variable as a **bit-pattern rather than a number.** For example I've made some lighting effects with the Arduino, and the on/off state of one light is represented by one bit in a variable. I have a 4-channel effect where the 4 lights are represented by the 4 least significant bits in a byte. So if I have a binary value of 00000101, the 4 lights are OFF-ON-OFF-ON (the 4 most significant bits are just ignored). That variable has a decimal value of 5, but I don't care about that. I have another lighting effect where the state of 24 LEDs are determined by the 24 least significant bits in a type long (32-bits). One of my lighting effects is a chase-light effect and I just use bit-shifting without ever knowing or caring about the numerical value of the variable.

The concept of a "bit pattern" isn't much different from other non-numerical variables/values... The **[u]ASCII[/u]** character 'A' is stored in memory as the binary "number" 00100001 (decimal 65). If we add one to that variable we now have an upper case 'B'. Only be knowing the context... The purpose of that binary number in memory... can we know if it's supposed to represent an 'A', or the number 65, or a machine code instruction, or something else. If you open a file with a hex editor, you'll see 'A' everywhere there's a byte equal to the decimal value 65 even if that value doesn't represent an 'A' in the file. The hex editor doesn't know the context.

**-** When working with bits & bit patters, we often use **hexadecimal** in the program. That's because **you can easily learn to convert variables of any size between binary and hex in your head.** That's not so easy with decimal. The reason it's easy is because each group of 4 bits converts *exactly* to one hex digit. That means you only have to learn 16 conversions. You already know one and zero, and some patterns/numbers are just "easy to remember".

Here are some example variables to demonstrate how these bit patterns (binary numbers) are easily converted to hex values.

NOTE - It's sort-of "traditional" to write binary numbers in groups of 4 bits to make it easier for humans to read and convert (although, you can't do that if you use binary numbers in your program/sketch because the compiler won't understand it.) So although there are really no spaces in the number, I'll write it as 0101 0101 instead of 01010101, etc.

0101 0101 (binary) = 55 (hex) = 85 (decimal)

0001 0001 (binary) = 11 (hex) = 17 (decimal)

0001 0101 (binary = 15 (hex) = 21 (decimal)

1010 1010 (binary) = AA (hex) = 170 (decimal)

0111 0111 (binary) = 77 (hex) = 119 (decimal)

1111 1111 (binary) = FF (hex) = 255 (decimal)

0101 0101 0101 0101 (binary) = 5555 (hex) = 21,845 (decimal)

...I did the hex conversions in my head, but I used a calculator to get the decimal values, except I did already knew that a byte full of ones (the maximum value of a byte) is 255 (decimal) or FF (hex).