How Do You Design a Raspberry Pi HAT (ID EEPROM and Mechanical Spec)?

Detailed Explanation

"HAT" is used loosely across a lot of Raspberry Pi documentation and third-party product listings to mean any 40-pin add-on board, but the term formally refers to a board that follows a published specification maintained in the raspberrypi/hats repository. That specification defines two mostly independent things: a mechanical/electrical envelope every compliant board should fit, and an optional ID EEPROM mechanism that lets the Pi auto-configure itself for the board. A board can follow one without the other, and understanding which parts matter for a given design is most of the actual decision-making involved in laying one out.

The Mechanical and Electrical Envelope

The specification defines the standard 40-pin GPIO header footprint and pin assignment (shared with every other Pi add-on board), a defined board outline and mounting-hole pattern that matches the Pi's own four mounting holes, and a maximum component height on the underside of the board so it clears the Pi's own components when stacked directly on top. It also defines a keep-out zone around the header and mounting holes so a HAT doesn't foul the Pi's USB/Ethernet connectors or, on boards that need it, the camera and display connectors. None of this is enforced by firmware. A board that ignores the mechanical spec still works electrically; it just may not stack cleanly, may block another connector, or may not fit an enclosure designed around the standard envelope.

The ID EEPROM and Automatic Configuration

The more distinctive part of the specification is the ID EEPROM: a small I2C EEPROM, typically a 24LC32-class part (or a smaller-capacity equivalent, since the actual data written is usually well under the chip's full capacity), wired to a dedicated pair of pins (ID_SD/ID_SC, physical pins 27 and 28) that are electrically separate from the general-purpose I2C-1 bus used for the rest of the board's sensors and peripherals. At a fixed, reserved address (0x50), this EEPROM stores a small binary-formatted record: a vendor and product identity, a UUID, GPIO drive-strength and pull configuration hints for the pins the HAT actually uses, and, most usefully, a compiled device tree overlay blob.

At boot, the Pi's firmware reads this EEPROM before the kernel starts, and if it finds valid HAT identification data, it applies the embedded device tree overlay automatically, exactly as if the user had added the equivalent dtoverlay= line to config.txt by hand. This is what lets a HAT "just work" when plugged in: the correct I2C, SPI, or GPIO configuration for the board's specific peripherals loads without the end user editing a configuration file or even knowing device tree overlays exist. For a commercial product built around a Pi or CM4/CM5 where the end customer is not expected to touch config.txt, this auto-configuration is the main practical reason to implement the full HAT specification rather than shipping an add-on board that requires a manual setup step in the product's own documentation.

Practical Examples

A sensor-array HAT that exposes an I2C environmental sensor, an SPI ADC, and a couple of GPIO-driven status LEDs is a typical case. Its designer wires the sensor and ADC to the standard I2C-1 and SPI0 buses, writes a device tree overlay that declares those peripherals with the correct addresses and chip-select assignments, compiles it, and programs it into the board's ID EEPROM along with the vendor and product identity. A user plugging that HAT into a fresh Raspberry Pi OS install sees the sensor and ADC appear as working Linux devices immediately after boot, with no config.txt editing required, because the firmware loaded the overlay automatically from the EEPROM. A board without the EEPROM, wired identically, works exactly as well electrically, but the user (or the product's own provisioning image) has to add the equivalent dtoverlay= line manually before the same devices become accessible.

Design Considerations

• Decide whether auto-configuration is actually needed before adding the EEPROM. For an internal engineering tool, a prototype, or a product where the carrier's software image is built and provisioned entirely by the manufacturer (a common case for a CM4/CM5-based product, since the OS image itself can already include the right dtoverlay= line at build time), the ID EEPROM adds cost and complexity for a convenience the end user may never encounter. It earns its place on a board meant to be plugged into a stock, unmodified Raspberry Pi OS install by someone who shouldn't have to edit config.txt.
• Keep the ID EEPROM's I2C pins electrically isolated from the rest of the board's I2C bus. ID_SD/ID_SC (pins 27/28) are physically separate from the general-purpose I2C-1 pins specifically so the fixed 0x50 EEPROM address never collides with anything else on the board's own I2C peripherals; routing the ID EEPROM onto the same bus as other I2C devices reintroduces the address-collision risk the separate pins exist to avoid. See how I2C addressing and multiple devices on a shared bus work for the general addressing constraint this sidesteps.
• Respect the mechanical keep-out zones even on a board that skips the ID EEPROM. The standard mounting-hole pattern and maximum component height exist independently of the EEPROM mechanism, and a board that ignores them can still physically conflict with the Pi's own connectors or a standard enclosure, even though it will function electrically.
• Budget the HAT's current draw against the Pi's GPIO header power limits, not just its own regulator's capacity. The 40-pin header's 3.3 V and 5 V rails have limited current budgets shared across every device connected to them; a HAT drawing more than the header can supply needs its own dedicated power input rather than pulling everything from the Pi's header, the same design constraint covered generally in Raspberry Pi GPIO interfacing.
• On a CM4/CM5 carrier board, the HAT specification doesn't directly apply. A carrier board replaces the Pi's own board-to-board connector and header entirely rather than stacking on top of a standard 40-pin Pi, so the mechanical envelope and connector layout are defined by the CM4/CM5 datasheet, not the HAT spec. A carrier board can still choose to expose a standard 40-pin header for HAT compatibility, but that's a carrier-board design decision, not a HAT-specification requirement.
• Custom HAT and carrier board layout: routing the ID EEPROM's isolated I2C pins correctly, meeting the mechanical envelope, and programming the EEPROM's device tree overlay data are all part of the PCB layout work Zeus Design's PCB design team handles for Raspberry Pi–based product hardware.

Common Mistakes

• Wiring the ID EEPROM to the general-purpose I2C-1 bus instead of the dedicated ID_SD/ID_SC pins. This defeats the entire point of the reserved pins and address, and risks an address collision with any other I2C device on the board using 0x50 or an overlapping address range.
• Assuming the ID EEPROM alone makes a board a compliant HAT. Without also meeting the mechanical envelope (mounting holes, keep-out zones, component height), a board can auto-configure correctly and still fail to physically fit a case or stack designed around the standard footprint.
• Programming the EEPROM with an incorrect or malformed device tree overlay and not testing on a clean OS image. A HAT developed and tested only on a Pi that already has the needed overlay manually configured in config.txt can appear to work perfectly, masking the fact that the EEPROM data itself is broken and the auto-configuration path has never actually been exercised.
• Designing to the original HAT specification when the product specifically needs Pi 5 PCIe support, then discovering the HAT+ revision's connector and EEPROM format requirements apply and the original spec's guidance doesn't cover them.