How to Read and Use a Hexadecimal List in ESP32 and Arduino Code

A hexadecimal list is a sequential array of base-16 numbers (using digits 0-9 and letters A-F) used in embedded programming to efficiently store memory addresses, device IDs, or hardware register configurations. When you write firmware for microcontrollers like the ESP32 or ATmega328P, you are ultimately manipulating physical voltage states in silicon registers, and base-16 provides the most direct human-readable bridge to those binary states.

What a Hexadecimal List Actually Changes in Your Firmware

Using a hexadecimal list instead of a decimal array does not change the underlying binary data compiled into the microcontroller's flash memory, but it fundamentally changes how you interact with hardware peripherals. Microcontroller registers are built in 8-bit, 16-bit, or 32-bit widths. Because one hexadecimal digit represents exactly four binary bits (a nibble), a two-digit hex value like 0xFF maps perfectly to an 8-bit register.

What this changes in a real circuit installation is your ability to configure communication protocols without performing mental base-10 math. If you need to set the upper four bits of an I2C control register high and the lower four bits low, writing 0xF0 instantly communicates the bit-mask to any engineer reading your code. Writing the decimal equivalent (240) forces the reader to manually convert the number to verify the bit states.

Worked Numeric Example: Building an I2C Address Whitelist

Let's look at a practical scenario. You are building an environmental monitor using an ESP32 DevKit v1. Your I2C bus has multiple devices, but you want your firmware to ignore unknown addresses and only initialize a specific set of sensors: an SSD1306 OLED display (0x3C), an MPU6050 accelerometer (0x68), and a BME280 environmental sensor (0x76).

Instead of writing a massive chain of if/else statements, you define a hexadecimal list as a constant array. By declaring it const, the compiler stores it in flash memory rather than consuming precious SRAM.

// Define the hexadecimal list of known I2C addresses
const uint8_t i2c_whitelist[] = {0x3C, 0x68, 0x76};
const uint8_t whitelist_size = sizeof(i2c_whitelist) / sizeof(i2c_whitelist[0]);

void scanI2CBus() {
  for (uint8_t address = 1; address < 127; address++) {
    Wire.beginTransmission(address);
    uint8_t error = Wire.endTransmission();
    
    if (error == 0) {
      bool is_known = false;
      // Check scanned address against our hexadecimal list
      for (uint8_t i = 0; i < whitelist_size; i++) {
        if (address == i2c_whitelist[i]) {
          is_known = true;
          break;
        }
      }
      
      if (is_known) {
        Serial.print("Known device found at 0x");
        Serial.println(address, HEX);
      }
    }
  }
}

In this example, the hexadecimal list {0x3C, 0x68, 0x76} consumes exactly 3 bytes of flash memory. When the scanner detects a device at decimal address 60, the compiler automatically matches it against the hex literal 0x3C because both resolve to the binary value 00111100. According to the official Arduino Wire library documentation, scanning the entire 7-bit address space takes roughly 100 milliseconds, making this list-based filtering highly efficient for boot sequences.

Where You Meet This in Practice

Hexadecimal lists appear constantly across digital electronics and embedded systems. You will rarely write a complex driver without encountering them in the following scenarios:

• WS2812B (NeoPixel) Color Arrays: Addressable RGB LEDs require 24-bit color values. A hexadecimal list is the standard way to define color palettes, such as uint32_t colors[] = {0xFF0000, 0x00FF00, 0x0000FF}; for red, green, and blue. The Adafruit NeoPixel guide relies heavily on this format for gamma correction tables.
• MAC Address Filtering: When configuring WiFi or Bluetooth Low Energy (BLE) on an ESP32, MAC addresses are passed as 6-byte hexadecimal lists (e.g., uint8_t mac[] = {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};).
• SPI Command Sequences: Displays like the ILI9341 TFT require initialization sequences consisting of dozens of hexadecimal register commands and their corresponding data arguments.
• Font and Bitmap Data: OLED libraries store pixel maps as long hexadecimal lists, where each hex byte represents an 8-pixel vertical column on the screen.

Formatting Rules and Common Syntax Traps

While the compiler handles the conversion, improper formatting of a hexadecimal list will result in silent data truncation or compilation errors. Below is a reference table mapping common 8-bit register values across number systems.

Trap 1: Forgetting the 0x Prefix. If you write {3C, 68, 76} without the 0x, the compiler will throw an error because C is an undeclared variable. If you write {10, 20} intending hex, the compiler reads them as decimal 10 and 20 (hex 0x0A and 0x14), leading to mysterious peripheral failures.

Trap 2: Exceeding Variable Width. If you define a list as uint8_t (max value 0xFF) but include a 16-bit value like 0x1FF, the compiler will truncate the upper byte, silently storing 0xFF and breaking your logic. Always match your list data type (uint8_t, uint16_t, uint32_t) to the maximum value in your sequence.

Trap 3: Endianness in 16-bit Lists. When sending a hexadecimal list of 16-bit values over I2C or SPI, remember that many microcontrollers are little-endian, while network protocols and some sensors expect big-endian. The Espressif I2C API documentation details how byte-ordering must be explicitly managed when passing multi-byte hex arrays to hardware FIFO buffers.