Converting Binary to Decimal and Hex: Quick Reference for Microcontrollers

If you are reading an 8-bit microcontroller register—such as an ESP32 GPIO input register or an I2C sensor status byte—and you see the bit pattern 11010110, you are looking at a high logic state on pins 7, 6, 4, 2, and 1. However, the final decimal value you use in your C++ code depends entirely on whether the hardware defines that register as an unsigned integer, a signed two's complement integer, or a raw data payload requiring bitwise recombination.

The Conversion Formula and Step-by-Step Math

Converting binary (base-2) to decimal (base-10) relies on a polynomial expansion where each bit position represents a power of 2, starting from $2^0$ on the far right (the Least Significant Bit, or LSB). For an 8-bit byte, the positions range from $2^0$ to $2^7$.

Here is the exact formula with the values substituted for 11010110:

(1 × 2^7) + (1 × 2^6) + (0 × 2^5) + (1 × 2^4) + (0 × 2^3) + (1 × 2^2) + (1 × 2^1) + (0 × 2^0)

= 128 + 64 + 0 + 16 + 0 + 4 + 2 + 0

= 214

To convert this to hexadecimal (base-16), split the 8-bit byte into two 4-bit nibbles. The left nibble 1101 equals 13 (Hex D), and the right nibble 0110 equals 6 (Hex 6), yielding 0xD6.

8-Bit Binary Conversion Table (Neighboring Values)

When debugging SPI or I2C traffic on a logic analyzer, you rarely see just one isolated byte. Below is a reference table of neighboring binary values (stepping by 2) to help you verify your mental math or logic analyzer decoding.

What Assumptions Fix Your Binary Conversion?

In power electronics, converting watts to amps requires assuming a voltage and power factor. In embedded systems, converting binary to decimal requires assuming a data type, bit-width, and endianness. If you get these wrong, your decimal conversion will be mathematically correct but functionally useless.

1. Signed vs. Unsigned (The Two's Complement Assumption)

The binary sequence 11010110 has a leading 1. In an unsigned 8-bit integer (like an Arduino byte), that leading 1 simply adds 128 to the total, giving 214. However, if the sensor datasheet specifies a signed 8-bit integer (common for temperature offsets or accelerometer axes), that leading 1 indicates a negative number. Using two's complement, you invert the bits (00101001), add 1 (00101010 = 42), and apply the negative sign to get -42.

2. Bit-Width and Sign Extension (8-bit vs 16-bit vs 32-bit)

How the answer shifts depends on the register width. If you read 11010110 from an 8-bit register and cast it to a 16-bit signed integer in C++, the compiler will perform sign extension. Because the MSB is 1, it pads the upper 8 bits with 1s, resulting in 11111111 11010110 (0xFFD6), which remains -42. If you cast it to a 16-bit unsigned integer, it pads with 0s (0x00D6), yielding 214. Always explicitly cast your variables to uint8_t, int16_t, etc., to force the compiler's hand.

3. When the Conversion is Meaningless

Converting raw binary to decimal is entirely meaningless in two common scenarios:

• IEEE 754 Floating Point Data: If a 32-bit binary payload represents a float (e.g., 01000000010010010000111111011011), converting it via standard base-2 polynomial math yields 1,078,525,915. But in IEEE 754 format, that exact binary sequence represents 3.14159. You must use a union or memcpy in C++ to interpret the bits as a float.
• Unknown Endianness in Multi-Byte Sensors: If you read two bytes from an MPU6050 accelerometer—say 11010110 (High) and 00101011 (Low)—the decimal value shifts wildly based on endianness. Big-endian yields 0xD62B (54,827). Little-endian yields 0x2BD6 (11,222). Without checking the datasheet for byte order, the decimal conversion is a guess.

uint8_t myRegister = 0b11010110;
Serial.println(myRegister); // Outputs: 214

uint8_t reg = 0b11010110;
bool pin4State = (reg & (1 << 4)) != 0; 
// (1 << 4) creates 0b00010000. 
// ANDing it with reg isolates that specific bit.