How Are Negative Numbers Represented in Binary: Two's Complement Explained

Negative numbers in binary are predominantly represented using Two's Complement, a mathematical system where the most significant bit (MSB) carries a negative weight, allowing microcontrollers to handle subtraction as addition without needing separate hardware logic. If you are writing firmware for an Arduino, ESP32, or Raspberry Pi Pico, this isn't just abstract computer science—it is the exact mechanism your processor uses to interpret sub-zero temperature readings, reverse motor velocities, and differential ADC voltages. People commonly confuse Two's Complement with Sign-Magnitude representation, falsely assuming that a negative number is just a positive number with a '1' slapped onto the front bit. That assumption will cause catastrophic wrap-around errors in your code.

The Math: A Worked Numeric Example of Two's Complement

To understand how the hardware actually stores these values, let's look at a concrete 8-bit example. We want to represent the decimal number -42 in an 8-bit signed integer (like an int8_t in C++).

1. Start with the positive binary: Positive 42 in 8-bit binary is 0010 1010.
2. Invert all the bits (One's Complement): Flip every 1 to a 0, and every 0 to a 1. This gives us 1101 0101.
3. Add 1 to the result: 1101 0101 + 0000 0001 = 1101 0110.

The binary sequence 1101 0110 is how your microcontroller stores -42. But how does the ALU (Arithmetic Logic Unit) read it back? It assigns a negative weight to the MSB. In an 8-bit system, the bit positions are weighted: -128, 64, 32, 16, 8, 4, 2, 1.

Let's verify our answer by summing the weights of the '1' bits in 1101 0110:

• Bit 7 (MSB): 1 × -128 = -128
• Bit 6: 1 × 64 = 64
• Bit 4: 1 × 16 = 16
• Bit 2: 1 × 4 = 4
• Bit 1: 1 × 2 = 2

Summing those up: -128 + 64 + 16 + 4 + 2 = -42. The math holds up perfectly, and more importantly, the processor can add 0010 1010 (42) and 1101 0110 (-42) together using standard binary addition, resulting in 0000 0000 (with the 9th carry bit discarded), yielding exactly zero.

Where You Meet This in Practice: Sensors and Microcontrollers

You will encounter Two's Complement constantly when reading digital sensors over I2C or SPI, or when dealing with differential analog measurements. Here are the three most common bench scenarios where this representation dictates your code's success:

1. I2C Environmental Sensors: Chips like the BME280 or BMP390 return temperature and pressure data as raw binary registers. If the ambient temperature drops below 0°C, the sensor outputs a Two's Complement value. If your C++ code reads this into an unsigned variable, the negative sign is lost, and the value wraps around to the top of the 16-bit or 24-bit range.
2. Accelerometers and Gyroscopes: An MPU6050 measures acceleration in three axes. When you tilt the board backward, the Z-axis acceleration becomes negative. The sensor's internal ADC outputs this as a 16-bit Two's Complement integer.
3. Differential ADC Readings: If you are using an external ADC like the ADS1115 to measure a shunt resistor for current sensing, current flowing in the reverse direction yields a negative voltage. The ADS1115 natively outputs this as a 16-bit Two's Complement word.

For a deeper look at how microcontrollers handle these data types natively, refer to the Arduino Language Reference on integer data types, which explicitly outlines the bit-width and signedness of standard variables.

Real-World Scenario Walkthrough: The I2C Accelerometer Bug

Let's look at a classic failure mode that happens when a maker misunderstands binary representation. Think of an unsigned integer like a mechanical car odometer that only rolls forward; when it hits 999,999 and adds one, it wraps to 000,000. Two's complement gives the odometer a reverse gear, but only if you tell the software to use it.

The Numbers: The robot is tilted slightly backward. The MPU6050 outputs the raw 16-bit binary value 1111 1111 1111 1010. In Two's Complement, this represents -6 (a slight backward tilt).

The Mistake: In your ESP32 C++ sketch, you read the high and low registers and combine them into an unsigned int (or uint16_t) instead of a signed int16_t.

// The flawed code
uint16_t raw_z = (Wire.read() << 8) | Wire.read(); 
// raw_z becomes 65530 instead of -6

The Outcome: The variable raw_z is now 65,530. You pass this massive positive number into your PID loop. The algorithm interprets this as the robot experiencing 65,000 Gs of upward acceleration.

What Went Wrong: The PID loop panics and commands the motor driver to 100% PWM in the forward direction to 'correct' the impossible tilt. The robot violently launches itself forward off your workbench, snapping the chassis. The hardware didn't fail; the binary representation was simply cast into the wrong data type, stripping the negative weight of the MSB and turning a small negative number into a massive positive one.

Signed vs. Unsigned Data Types: The Root of Bench Headaches

To prevent the scenario above, you must explicitly match your C++ data types to the sensor's datasheet. Here is a comparison of how an 8-bit binary sequence is interpreted depending on the data type you assign in your code.

Notice the asymmetry in the signed range: it goes from -128 to +127. This is because 0000 0000 claims the 'zero' slot, leaving one extra slot on the negative side. If you are mapping a signed 16-bit sensor reading (-32,768 to 32,767) to a 0-5V PWM output, you must mathematically shift the data by adding 32,768 before mapping, otherwise your negative values will wrap around and destroy your scaling math.

For a comprehensive breakdown of the underlying digital logic and why hardware designers chose this specific method over sign-magnitude, the All About Circuits digital textbook chapter on binary addition and subtraction provides excellent schematic-level context on ALU design.

Frequently Asked Questions