Raspberry Pi introduces HATs

Users attaching an add-board to the model A or B Pi usually have to work out which drivers are required for their specific board, and then edit the relevant Linux files to make them load at boot time before the board is usable (or load them by hand from the command line). The Raspberry Pi has no knowledge of whether it has a board attached or not, and the various drivers, when loaded, will simply assume that they can make exclusive use of the GPIO interface. Most of the time this all works OK, but it can be a bit challenging for new users. Linux drivers blindly assuming GPIO pins are available can also occasionally cause confusion.

The Raspberry Pi B+ has been designed specifically with add-on boards in mind and today we are introducing ‘HATs’ (Hardware Attached on Top). A HAT is an add-on board for B+ that conforms to a specific set of rules that will make life easier for users. A significant feature of HATs is the inclusion of a system that allows the B+ to identify a connected HAT and automatically configure the GPIOs and drivers for the board, making life for the end user much easier!

Before we go any further, it is worth noting that there are obviously a lot of add-on boards designed for the original model A and B boards (which interface to the original 26 way GPIO header). The first 26 pins of the B+ GPIO header are identical to those of the original models, so most existing boards will still work. We are not breaking compatibility for existing boards; we’re creating a specification that B+ add-on board designers can follow (if they so wish), which is designed to make end users’ lives much easier.

In a nutshell a HAT is a rectangular board (65x56mm) that has four mounting holes in the (nicely rounded) corners that align with the mounting holes on the B+, has a 40W GPIO header and supports the special autoconfiguration system that allows automatic GPIO setup and driver setup. The automatic configuration is achieved using 2 dedicated pins (ID_SD and ID_SC) on the 40W B+ GPIO header that are reserved for an I2C EEPROM. The EEPROM holds the board manufacturer information, GPIO setup and a thing called a ‘device tree‘ fragment – basically a description of the attached hardware that allows Linux to automatically load the required drivers.

What we are not doing with HATs is forcing people to adopt our specification. But you can only call something a HAT if it follows the spec.

So why are we bothering with all this? Basically, we want to ensure consistency and compatibility with future add-on boards, and to allow a much better end-user experience, especially for less technically aware users.

The Raspberry Pi Foundation: http://www.raspberrypi.org/introducing-raspberry-pi-hats/

Raspberry Pi HAT