Signed Integer in Binary: Microcontroller Sensor Data & Two's Complement

A signed integer in binary is a digital number format that uses the most significant bit (MSB) to indicate whether the value is positive or negative, allowing microcontrollers to process data below zero. When you wire up a sensor to an ESP32 or Arduino, this concept dictates whether your code reads a physical sub-zero measurement correctly or crashes into a massive overflow error. In a real circuit or installation, using the correct signed format changes how the microcontroller's Arithmetic Logic Unit (ALU) interprets raw I2C or SPI register bytes, ensuring a negative physical value—like a dropping ambient temperature, a reverse-biased shunt current, or a backward tilt on an accelerometer—isn't misread as a massive positive spike that could trigger a faulty relay or halt a PID control loop.

The Core Mechanism: Two's Complement Math

Modern microcontrollers, from the ATmega328P on an Arduino Uno to the dual-core Xtensa LX6 on an ESP32-WROOM-32, do not use a dedicated "minus sign" bit in the way humans write numbers. Instead, they rely on a system called two's complement. In this system, the MSB acts as a negative weight. For an 8-bit register, the bits represent values from +64 down to +1, but the MSB represents -128, not +128.

A Worked Numeric Example

Let's look at how an 8-bit ALU handles the number 5 and -5. This is exactly what happens inside the silicon when your code executes a subtraction that crosses zero.

• Positive 5: In standard binary, this is 0000 0101. The MSB is 0, indicating a positive value.
• Negative 5: To find -5, the ALU takes the binary for +5 (0000 0101), flips every bit (one's complement: 1111 1010), and adds 1. The result is 1111 1011.

If you add these two binary numbers together on the bench (0000 0101 + 1111 1011), the result is 1 0000 0000. Because we are limited to 8 bits, the 9th bit (the carry) is discarded, leaving 0000 0000. The math perfectly resolves to zero without the processor needing specialized subtraction hardware. This elegant hardware efficiency is why two's complement is the universal standard for signed integers in digital electronics.

Where You Meet This in Practice

You will encounter signed binary formatting constantly when moving beyond blinking LEDs and into physical measurement and control systems. Here is where it dictates your circuit's behavior:

• Digital Temperature Sensors: Chips like the TI TMP117 or Maxim DS18B20 output 16-bit signed registers. A reading below 0°C relies entirely on the MSB to tell your HVAC controller to switch from cooling to heating.
• Bidirectional Current Sensors: When measuring battery charge/discharge rates with an INA219 or a Hall-effect sensor (like the ACS712), the ADC outputs a signed value. Positive indicates charging; negative indicates discharging.
• Motor Control & Encoders: Quadrature encoders track position using signed integers. Moving clockwise increments the value; moving counter-clockwise decrements it, crossing through zero seamlessly.
• IMU and Accelerometer Data: The MPU6050 outputs signed 16-bit integers for X, Y, and Z axes. Gravity pulling "down" on the Z-axis might read +16384, while flipping the board upside down yields -16384.

Real-World Scenario Walkthrough: The Winter Overflow Crash

Abstract theory is fine, but mismanaging signed integers destroys real-world installations. Here is a classic field failure involving an ESP32 and an I2C temperature sensor.

1. The Setup: You are building an outdoor smart-freezer monitor using an ESP32-WROOM-32 and a TI TMP117 digital temperature sensor. The sensor communicates via I2C, and the temperature register (0x00) returns a 16-bit value. You write your Arduino sketch using uint16_t (unsigned 16-bit integer) to store the raw I2C bytes because you read online that I2C registers are "just bytes."
2. The Numbers: In the summer, the freezer reads -18.0°C. The TMP117 outputs the hex value 0xFF4C. Wait, let's look at a cleaner number: exactly -10.0°C. The sensor outputs 0xFFF6.
3. The Outcome: Your code reads 0xFFF6 into the uint16_t variable. Because the variable is unsigned, the ESP32 interprets the MSB as +32768. The variable reads 65526. Your code multiplies this by the sensor's resolution (0.0078125°C per LSB), resulting in a calculated temperature of 511.9°C.
4. What Went Wrong: Your logic assumes the freezer is on fire. The ESP32 triggers an emergency shutdown relay, cutting power to the compressor, and sends you a panic SMS. The actual temperature was a perfectly safe -10.0°C. The failure wasn't the sensor or the wiring; it was a C++ variable type mismatch. Declaring the variable as int16_t (signed) would have forced the ALU to treat 0xFFF6 as -10, yielding the correct physical measurement.

Common Confusions: Signed vs. Unsigned and Bit Shifting

When debugging I2C/SPI data on the bench, hobbyists frequently confuse signed integers with unsigned integers, or they misunderstand how bitwise operations affect the sign. Below is a breakdown of what people commonly confuse this concept with.

The Bitwise Sign Extension Trap

Another massive point of failure occurs when reading high-resolution ADCs that don't perfectly align with standard 8, 16, or 32-bit boundaries. Consider a 12-bit signed ADC reading a bipolar analog signal. The maximum 12-bit value is 0xFFF. If the ADC outputs 0x845, the MSB of that 12-bit word (bit 11) is 1, meaning it's a negative number.

If you drop 0x845 into a standard 16-bit signed integer (int16_t), the microcontroller sees it as positive 2117, because bit 15 (the 16-bit sign bit) is 0. You must manually perform sign extension in your code to tell the 16-bit register that the 12-bit sign bit should be propagated across the upper unused bits:

int16_t raw_12bit = 0x845;
// Check if the 12-bit sign bit (bit 11) is set
if (raw_12bit & 0x800) {
    raw_12bit |= 0xF000; // Force upper 4 bits to 1
}

Without this bitwise manipulation, your control loop will violently overcorrect, thinking a slight negative error is actually a massive positive surge. For more on how the ESP32 handles I2C data types natively, refer to the Espressif I2C API documentation.

FAQ: Troubleshooting Binary Sign Errors