News

All news

Introducing Raspberry Pi HATs

Just over two weeks ago, we announced the new Raspberry Pi B+ with immediate availability. We’ve been very pleased at the response from the community and press about the B+, and most people seem to appreciate why we decided to evolve the Model B in the way we did – lots of you have been in touch to tell us how much you’re enjoying your new B+.

There are many great new features built into the B+, but today we want to talk about one new feature we are particularly excited about.

One of the brilliant things about the Raspberry Pi has always been the ability to attach physical hardware to the Raspberry Pi’s GPIO (General Purpose Input/Output) connector. There are so many third party add-on boards that attach to the Raspberry Pi and extend its functionality: motor controllers, LEDs, buttons, sensors, microcontrollers, LCDs, ADCs and DACs; you name it, someone has almost certainly created an add-on board that makes it usable with the Raspberry Pi.

Model B’s 26W vs Model B+’s 40W GPIO connectors

On the Raspberry Pi models A and B, the GPIO connector has 26 pins. 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.

So what is a HAT?

B+ sporting a (mechanical sample of a) HAT and showing camera and display connections

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 HAT specification is available on GitHub for those wishing to design add-on boards for the B+. As previously explained, there is no requirement to follow the HAT specification, but we encourage people to think about following it if possible, as it will make the world a better place for end users.

One final bit of good news: we have used a surface mount connector on our internal prototype HAT which works very nicely. As you can see from the pictures it solders to the top of the board and then fits over an extension header (the extension header pins push through the HAT from underneath). As the extension headers push through like this it is possible to either use a short, flush mounting extension or a version with longer pins that poke out above the HAT and allow further access to the GPIO pins for debugging.

HAT using extender with longer pins

For HAT designers wanting to use these connectors, we have secured discounted pricing through Toby Electronics. The connector part numbers are:

REF-182665-03 = £0.57 each (surface mount connector without locating peg)
REF-182665-01 = £0.67 each (surface mount connector with locating peg)
REF-182683-02 = £0.56 each (extension header short pins)
REF-182684-02 = £0.64 each (extension header long pins)

Toby tell us they are getting stock in now, which should arrive for the 5th August.

Please post technical questions about the specification to the forum.

77 comments

Very cool! We hope to try out the HAT spec soon!

The idea ist great, but it would be nice of you to mention, that it is borrowed from the beaglebone capes.

There’s only so many ways you can attach a board to another board with pin headers.

There’s also only so many ways you can provide auto-configuration for hardware that does not inherently support it. Embedding device tree is the preferred method for ARM Linux since this is now the recommended method of instantiating and configuring hardware on boot.

Expansion boards using this sort of design are not new – in fact as an industrial example the PC-104 form factor and expansion boards have been around for ages, and are widely used in industry in embedded computers.

Am I the only one who thinks there is something really special under that white card?!?

The attached display connector ribbon is promising…

There’s nothing attached to the white card. Both of the flat cables are connected to the Pi below.

Whoa, no shit?

Guess so, too. Especially because there’s the official logo printed on the board. C’mon, Pi Towers, what do you hide???

/OliverH

I bet its a DMC Delorean compatible Flux Capacitor so we can go back in time!

Or a theremin add on!

I don’t mind either way!

I’m curious as to whether HATs will be stackable like Arduino shields?

Stackable HATs featured in the specification discussion – but eventually it was thrown out due to the large increase in complexity of autoconfig and potential for user error.

Stacking is implicitly not supported for HATs, but you can design non-HAT stacking boards using the example surface-mount connector scheme.

When and where will the first HATs be available?

Trying to get my head around this.
Is it just a blank PCB with a full 40 pin header and 4 corner holes?

I suppose the white card indicates the working area

Would be nice to see it without the card on top and an underneath view.

“Is it just a blank PCB with a full 40 pin header and 4 corner holes?”

Nope, it’s a design-specification for people who make add-on boards for the B+ to make use of. The example image just shows the physical size of a HAT board. A blank PCB wouldn’t be a valid HAT as it doesn’t include an EEPROM.

even if it turns out that there’s nothing substantial under paper and the board has a few bits and pieces, its still valuable to use it as an elevated clean slate to be able to use other boards and shields ( like Dave Akermans new release a few days ago ) without bovver of hittin’ extraneous things

in fact i’d be excited by what it takes away, like holes..
A largish hole to mount a small low profile fan, and other holes to bring mounting into compatibility with earlier boards

Is it me or should the HAT board have a whole cut out to the edge and not only a rectangular hole for the PiCam cable to be attached onto the RPi first before the HAT being put on?

If you look at the mechanical specification drawing, it shows the example (preferred) cutout for the DSI and CSI ribbons.

That shows a hole, rather than a slot. A slot would allow mean you could plug in the HAT independently of the camera connectors.

… but the free market will solve that, because HAT makers will realise this is a better thing to do and hence make them more money :-)

“because HAT makers will realise this …”
even the mad ones ?

It’s not like it’ll be impossible to connect/disconnect the camera ribbon cable with the hat attached to the pi, but I agree with you.

Probably it’s a matter of having the most available space possible, since the HAT boards will have a small footprint (3640 square mm minus display cutout, camera slot, mounting holes and connector).

in that case it would make much more sense to leave the camera slit out altogether, the small bit of PCB closing the slit isn’t useful in any way, but removing the slit altogether would make a difference in useable surface. Can we still call it a HAT without the slit?

I’m all for opening the slot completely, mechanically it doesn’t matter, and making (non round) openings in PCB’s (compared to changing the outline of the board ) is quite costly. It would be so much more comfortable to have a slit than an opening that I don’t know why anybody would opt for an opening! Again mechanically it makes not one iota of difference when using 1.6mm standard FR4 PCB material.

P.S. If you look at the HAT specification, having the camera slit is only a recommendation, you can leave it out or extend it to the edge, and it still fulfills the requirements to be called a HAT.

I was badly confused by the 40W. I was thinking that 40 Watts is a bit too much for Raspi. But it seems to mean 40 Way Gpio. Wouldn’t it be clearer to talk about 40P (like 40 Pins)?

the pi now uses 40 watts

Thanks for posting this I too was wondering what on the earth 26W and 40W was referring to.

Raspberry Pi Hats OK let’s open a book on a few likely names
The Top , The Panama , The Bowler, etc etc

Presumably a ‘Hat’ could incorporate a few basic goodies of it’s own on it’s ‘brim'(tm) and describe them to the PI, a Real Time Clock springs to mind..

So, if it’s “hat” could use “red hat”, or “Fedora” :D

Hmm, methinketh that the white card is hiding something. This may be a bare PCB, but it is silk screened for R14 and R28 in one corner (just under the Ras logo) and clearly has surface mount pads for such components adjacent. The Foundation does not cover things like this for no reason. They’re up to something, but I guess we have to wait and see, eh Liz?

I’m saying *nothing*. :D

And we got a bite ;) Thanks, Liz: that *nothing* is enough!

… and your silence has eloquence beyond that of a thousand words :-)

Time to get the design board and c++ books out, and start on making an arcade HAT I think’s

2 player, 2 player and 4 player variants with different numbers of buttons.

Time to play

can’t wait to put on a fedora.

Looks like you can connect one of those old IDE cables. perfect.

Will it be possible to have a Robot Driver Hat to connect directly to motors?

Yes, of course, although the board would need a separate input for motor power.

I expect a plethora of such, and other boards, soon, as almost anybody can design them.

I hope electronic gurus like Lady Ada start designing and building hats for robots, Lego mindstorm (with 4 motors), 3d printers, house automation, bitcoin factories, servo controllers. Looking forward for them in the next six months!

A huge potential was left out of the expanded GPIO spec. They should have included a D+/D- USB pin pair. I think that would have been even more valuable than the addition of two USB A sockets on the back. HATs could have been developed to easily add, for example, serial devices without clobbering the Pi serial console, or mass storage (a 2.5″ hard disk HAT perhaps?).

USB2.0 requires carefully-controlled trace widths to maintain a specified differential impedance for the signals running at 480Mbit/s.

Routing these signals through a 0.1″ pitch header is a no-no as this will create a large discontinuity in the differential impedance. The result of this is a USB2.0 link that has a dramatically increased bit error rate (probably to the point of not working).

Nonsense. USB 2 is routinely sent through .1″ headers – in fact there’s a standard pinout for doing this. Look inside any desktop PC and you’ll see exactly this. I’m willing to bet the problems were: First – They wanted four normal USB ports for their primary use case. Second – if they mounted 4 full sized USB ports, they didn’t have enough space left on the board to mount a standard dual header. I suspect that the USB Implementers Forum (USB-IF) would get a bit touchy about non-standard pinouts…

There is no standard connector in the USB specification that references a 0.1″ pitch header pinout. All of the connectors defined in the specification are spring/land with a continuous metal shell that mates with the socket. The design guide for USB high-speed compliance specifically states that data lines should be kept as short as possible,

The 0.1 pitch headers in a PC are bracketed on each side by GND and VCC pins to somewhat alleviate the discontinuity. This means that to add D+ and D- to the GPIO header with some sane arrangement, we would have to add additional grounds on the GPIO header that would bring the pin tally for USB to at least 4, which would necessitate removing several GPIO pins from the header.

The other reason why you can get away with 0.1″ pitch headers in a PC case is that it’s a gigantic metal box. The Pi (and attached HAT) will typically be uncased. Impedance discontinuities on high-speed signal lines are a prime source of EMI: commercially-produced HATs would have to undergo compliance testing compatible with local law, which will include emissions testing.

It would be extremely unlikely that a HAT using a theoretical D+ and D- pin at USB2.0 high-speed, uncased, would pass EMC. This would preclude the sale of the combined device in a large number of jurisdictions.

USB full-speed would probably pass, but at 12Mbit/s you’re better off using alternative multi-bit buses available on the GPIO header (e.g. SD/SDIO).

For this reason alone, it’s not worth putting USB pins on the header.

Hmm…. A “Hard HAT”

There are probably dozens of Prince fans crying out “Why HAT – why not Beret?”. You could’ve had a theme tune for it and everything. #sackthemarketingteam! :D

Reference for younger viewers:
http://en.wikipedia.org/wiki/Raspberry_Beret

Maybe they wanted to imply that R-Pi accessories were not only “the kind you find in a second-hand store…” :-)

Even I want a HAT now!

Will Emma’s mum start mass-producing knitted Raspberry Pi HATs? ;)

We can but hope.

Darn- no stacking HATs. I was gonna call it “Gurkha mode”, as their military wear totally cool hats with doubled brim… which can’t be found *either*. I’ve looked…

Can’t wait to see what the aftermarket comes up with! Maybe some means of adding Pi to Pi to Pi…

… which I would call “Jervis Tetch” mode…

Gurkha hats aren’t issued any more. Take a look at ‘Tilley hats’; one of their range might be a suitable replacement.

I would call them “TOP-HATs”, get it? a HAT on top of another HAT.

In fact stackable I/O boards only really works if you restrict yourself to I/O systems that can also be “paralleled”, like I2c.

If you want to design your own “TOP” system on top of a HAT, I would opt for such a system, as any other solution would very soon become very cumbersome. don’t forget to also route the EEPROM signals to your TOP connector, so they can be included into the device tree. It would be nice if the EEPROM would automatically change its I2C address depending on the order of the stack, perhaps a few pins can set the address for the next level somehow, but I leave that as an exercise to the designer.

“don’t forget to also route the EEPROM signals to your TOP connector, so they can be included into the device tree. It would be nice if the EEPROM would automatically change its I2C address depending on the order of the stack”

I’d assume the RPi firmware (which does the EEPROM and device-tree cleverness) will only be programmed to look at the first EEPROM address..?

P.S. Actually I meant for them to be called “TOPs”.

TOP
TOP
TOP
HAT

Now to finally learn kicad or pay for eagle and design my own range of hats, get the pcbs done at dirtypcbs, next step profit. Oh wait, i’ve a wife and 2 year old, d’oh!….may have to wait till raspberry pi 3 before I get some quality ‘me time’ again :-p

Just checked Toby Electronic – parts (2 of each listed above) UKP 4.88. Ggggggggggg-rrrrrrrrrreat!

Delivery to Cyprus:

UKP 49.99

Guess I’ll be looking elsewhere.

Uhmmm. If I add it; then I found powered HD there or video peripheral. …..maybe both…. Yes. Would be great !!

sir i want to run RPi in my new laptop to use laptop screen its new and working laptop so how should i connect is there is any solution..
thnx..

Have a look at http://pihw.wordpress.com/guides/direct-network-connection/

This is cool. I can think of lots of fun things to come as a result.

I’ve seen some cool new PCB printers being announced and there’s a lot of work being done in that field right now. ( http://www.electronicsweekly.com/news/design/eda-and-ip/3d-pcb-printer-pick-n-place-2014-07/ )

It’s too bad the open source software isn’t further along. It’s not surprising though, it’s complex stuff and after looking into it KiCad is pretty good. Hopefully things like this and the CM will spur development for both the software and the printers.

It’s still almost hard to imagine, but it would be awesome to be able to print and assemble your own PCB on your desk top and it looks like it won’t be too long before we can (affordably).

I wonder if there are any PCB manufactures who will do discount for a HATS shaped board.

Many Chinese PCB manufacturers have very low (<$10) prices for low quantity dual sided PCB's smaller than 10×10 cm, as there is so many competition in the low tech PCB field.

Have you tested heat build in that confined space? Especially while overclocked and doing lots of graphical manipulation.

You mean for the broadcom SoC? No worries, its a chip designed to work inside the very small confinements of a smartphone.
As for the HAT logic, its on top, and so not confined.

Craftable HATs you say? Wait until the Team Fortress 2 crowd picks up on this.

~~Team Fortress 2~~ You mean Valve® Hat Simulator™ 2015 :)

Hat = shield ?

I don’t understand why hats include slots. Longer ribbons vs ugly holes in peripheral boards means I give the design a 2.

I guess the solution is to have a breakout board to take the ffc out sideways. Then subsequent hats don’t need/use the slot.

Having a whole hat that just takes it all out sideways would be a bit proflagate.

But a “brim” board that takes the FFC cable up and round to the side might work. Then you get an FFC slot just above the HDMI socket. Or along/slightly diagonally over the RJ45.

slits are optional in the HAT specification.

Anxiously awaiting Asynchronous Serial and Sata HAT. :-D

Top HAT I reckon! This is making me mad for peripherals… I must wait… I must wait… I must wait.

Hi Marc,I had a quick skim over the thread (I reacll reading your original post on the forum). My approach would be to use the Interrupt On Change (IOC) feature of PORTB in the PIC18F27J13 and then simply increment counters for low->high or high->low transitions on pins that change (old_PORTB XOR current_PORTB gives you the bits that have changed). Implement an I2C slave device on the PIC to access your counters.Alternatively use a timer interrupt to poll PORTB for changes every 1ms (for example), assuming the S0 pulses are long enough I read 50ms mentioned elsewhere. Polling will allow you to count on more than the four PORTB pins that have IOC.The PORTB or polling-timer interrupt should be serviced as high-priority, and the I2C interrupt as low priority, which means no pulses will be missed during I2C communications. In an I2C interrupt service routine (ISR), you should read counters twice to ensure they’re the same both times before sending back over I2C (because your counters will typically be unsigned long, and reads are not atomic).I used Cadsoft Eagle to draw the schematic, but created a custom component for the PIC18F27J13 I intend to post the C code and Eagle library when I get the time to pull it all together. The code will give you a ready-made I2C slave that you can modify for your project, but it’s not too difficult to implement.

Does anyone know if there is an Eagle library available for the SMT Samtec HLE headers?

Hi guys,
I’m screwed! Besides the other sensible HAT guidelines and RasPi features, IMHO you totally screwed up the mounting holes. I don’t know in which parallel universe you islanders live, but on the mainland I got used to M3 screws as a widely spread standard. They don’t fit in the 2.9mm/0.114in holes of the RPi nor in the 2.75mm/0.108in holes of the HAT. And I don’t want to use the rarely spread M2,5/#3/BA7. (Which screws have you used for the pic/do you use in GB?)
I’m currently designing a RPi B+ addon and I’m on the verge of making it a HAT, but I’m not willing to to screw the user by implementing 2.75mm holes – I will use 3.2mm mounting holes for M3 screws and threaded spacers instead. Can’t you weaken the mechanical specs and allow 3.2mm holes for M3 (as well as changing the RPi holes to 3.2mm or at least 3.0mm)? Otherwise I’m going to call my board BEANIE instead of HAT :P
Kind regards
Christian

Ils sont fous, les Bretons! (The Brits are crazy!)

from a physical design standpoint…

why not use surface mount dual-in-line footprints and include an identical, maybe optional HAB
(Hardware Attached on Bottom),
giving twice the IO in the same Pi footprint?

any add-on board, using thru hole DIL connectors,
could mount on top or bottom. also, a top-side surface mount DIL can be solder-pasted and machine mounted during manufacture…

How reasonable is it to have a “shield adapter” HAT to allow all those existing IO “Shields” work with the R.Pi? I think there is already something on the market for the 26-pin GPIO bus to take shields. Or is it a better approach to encourage a HAT alternative for every shield? How would you make such a combination copew with the I2C ID EEPROM system? Hmmm. But then again I’d love to see a tiny general purpose HAT with IO connectors for analogue inputs/outputs and able to drive MOSFETs, perhaps with a veroboard-like “play area” for through-hole devices… so something user-defined like that which would end up being impossible to describe fully in an ID EEPROM would have to be allowed for anyway, I guess.

Comments are closed

News

Latest posts

This massive nose sniffs things then prints a description of the smell

Paragraphica creates "photos" based on your location

Dragonfly Spectral Line Mapper

Refurbished vending machine

Next Post

Mathematica 10 - now available for your Pi!

Previous Post

Pi in the Sky: hardware for high-altitude balloonists from Dave Akerman

Share this post

77 comments

Stefan H.

jdb

wallarug

Misel

Connor Nishijima

OliverH

David Weaver

jdb

AndrewS

aremvee

aremvee

Arthur

jdb

Tom West

jokeerr

mahjongg

mahjongg

Juha

solar3000

Imagisaurus

Ken MacIver

Montekuri

Mark Daniels

Mark Daniels

Tom West

daniel

solar3000

Camillo

mahjongg

Bernardo

jdb

jdb

Doug

Peter Ryan

jbeale

Martin

AndrewS

Pygar

Pygar

Kwacka

mahjongg

AndrewS

mahjongg

dean

Kwacka

Laurus E

vikas

AndrewS

Matthew Manning

mahjongg

paddyg

mahjongg

Anthropy

Martyn Jones

Simon Armstrong

simon

mahjongg

James Denney

Kevin Davies

Christian

Obelix

almas

Mark Aitchison