How to Add Hexadecimal Numbers: A Practical Guide for Embedded Systems

Hexadecimal addition is the process of summing base-16 numbers, carrying over to the next positional column only when a column's total reaches 16 rather than 10. In a real embedded installation, accurate hex addition dictates how microcontrollers calculate memory offsets and configure hardware registers, directly determining whether a sensor initializes correctly or throws a hard fault. While decimal math is second nature, treating hex digits like base-10 is the fastest way to corrupt a data bus or overwrite critical firmware memory.

The Core Mechanism of Base-16 Addition

To add hex numbers reliably on the bench, you must internalize the mapping between the letters A-F and their decimal equivalents. When you add two hex digits, you are temporarily converting them to decimal in your head, summing them, and then converting the result back to hex.

What people most commonly confuse hex addition with is either standard decimal addition (where they carry over at 10) or binary addition (where they carry over at 2). Hex is simply a human-readable shorthand for binary. Every single hex digit represents exactly four binary bits (a nibble). When you add 0x1 to 0xF, you are flipping all four bits from 1111 to 0000 and carrying a 1 into the next nibble.

Step-by-Step: A Worked Numeric Example

Let's walk through a standard 16-bit memory address calculation. We need to add a base register address of 0x2A5F to a configuration offset of 0x13B8.

1. Rightmost Column (1s place): Add F and 8. F is 15 in decimal. 15 + 8 = 23. Since 23 is greater than 15, we subtract 16 to get our remainder: 23 - 16 = 7. We write down 7 and carry a 1 to the next column.
2. Second Column (16s place): Add 5, B, and the carried 1. B is 11. So, 5 + 11 + 1 = 17. Again, 17 is greater than 15. Subtract 16 to get 1. We write down 1 and carry a 1.
3. Third Column (256s place): Add A, 3, and the carried 1. A is 10. So, 10 + 3 + 1 = 14. 14 is less than 16, so no carry is needed. 14 in hex is E. We write down E.
4. Leftmost Column (4096s place): Add 2 and 1. 2 + 1 = 3. No carry. We write down 3.

The final sum is 0x3E17. If you were writing a C++ pointer for an ESP32, your new memory address is 0x3E17.

Where You Meet This in Practice

You rarely add hex numbers when wiring a 120V AC outlet, but in low-voltage DC and embedded systems, it is a daily requirement. Here is where base-16 math directly impacts your hardware:

• I2C Address Routing: When using an I2C multiplexer like the TCA9548A, you often need to calculate the logical address of a downstream sensor by adding a base address offset to the multiplexer's channel register.
• EEPROM Memory Mapping: External flash and EEPROM chips (like the AT24C32) use hex addresses to define read/write pointers. Miscalculating a page boundary offset will cause the memory buffer to wrap around and overwrite your data.
• RGB LED Color Mixing: Addressable LEDs (WS2812B) take 24-bit hex color codes. Blending two colors manually requires adding their hex RGB values and capping the result at 0xFF per channel.
• Subnetting and MAC Addresses: Network engineers configuring IoT gateways frequently add hex values to calculate the upper bound of a MAC address range or an IPv6 subnet prefix.

Real-World Scenario: The EEPROM Page Boundary Crash

Let's look at a scenario where failing to understand how to add hexadecimal numbers results in a bricked configuration sector on a custom PCB.

The Numbers: Your current write pointer is at 0x0F1C. You need to write a 53-byte payload. 53 in decimal is 0x35 in hex. To find the memory address immediately following your payload, you must add 0x0F1C + 0x0035.

What Went Wrong: The developer did the math in their head using decimal logic for the first column. They saw C (which they knew was 12) and added 5. 12 + 5 = 17. Applying base-10 rules, they wrote down a 7 and carried a 1. Moving to the next column: 1 + 3 + 1 (carry) = 5. The final column: F + 0 = F. They calculated the new pointer as 0x0F57.

The Outcome: The firmware wrote the payload, updated the pointer to 0x0F57, and proceeded to write the next batch of config data. However, the actual hex sum of 0x0F1C + 0x0035 is 0x0F51 (because 12+5=17; 17-16=1, carry 1). By aiming for 0x0F57, the microcontroller skipped 6 bytes of memory. Worse, because the developer misunderstood the page boundary wrap-around, the subsequent write operation crossed into a protected calibration sector, corrupting the device's factory trim data. The sensor permanently read 0.00 until the EEPROM was physically desoldered and re-flashed.

Common Pitfalls and Frequently Asked Questions