Close
0%
0%

Designing a Raspberry Pi HAT

How to design your own HAT module including ID EEPROM.

Similar projects worth following
How do you go about designing a HAT that is compatible with the Raspberry Pi standards? This project will walk through the resources needed to design your own and an example design for an Atomo adapter.

PART 1 (What is the HAT spec?)

Raspberry Pi HAT modules are a great open standard for adding functionality to a Pi that either needs additional hardware, or a better way to connect with the rest of the world. The Pi Foundation has a pretty good spec for what is needed to make a board officially HAT compatible, but it takes a little bit of reading and parsing. This page on the design guidelines has all of the specifics of what you need to consider when designing your HAT.

From the main page:

A board can only be called a HAT if:
It conforms to the basic add-on board requirements
It has a valid ID EEPROM (including vendor info, GPIO map and valid device tree information).
It has a full size 40W GPIO connector.
It follows the HAT mechanical specification
It uses a GPIO connector that spaces the HAT between 10mm and 12mm from the Pi (i.e. uses spacers between 10mm and 12mm).
If back powering via the GPIO connector the HAT must be able to supply a minimum of 1.3A continuously to the Pi (but ability to supply 2A continuously recommended).

Other details you need to know:

  1. There are specific GPIO sequencing that you need to be mindful of. By default, some pins are active at boot, so that can have unexpected results if there is no current limiting on whatever is connected to them.
  2. On pins 27 and 28, do not connect anything other than an EEPROM that is to the defined spec. You can leave off the EEPROM, but that is no longer officially a HAT. As long as you don't connect anything to those pins, the Pi Foundation would still probably be supportive, but you can't say it is a HAT.
  3. If you are back powering the Pi via the HAT, you need to not connect the 3.3V supply from the HAT to the Pi, and you need to put in protective components to prevent 5V via USB causing conflicting power issues.

So, that seems to be the lot of it, the Pi Foundation really tried to leave the rest as wide open as possible to let you be as clever as you want.

PART 2 (OK, so how do you design a HAT?)

Well, knowing the basics of what things you need to call your design a HAT is only a small part of it. The best resource I found for the details of what each pin is capable of is https://pinout.xyz/ If you check their GitHub you can find good resource files with all the functions defined in YAML format. Here is a good image based version of the same info.I know everyone may have their own way to approach this part of the design. Some people might start with a schematic with all the bits and then just start making connections, but what I have found is that doing this in a spreadsheet helps to both make it easier to parse all the options and to do some checking to see what is available and if the function you assigned to a particular pin is valid. You can find a spreadsheet version of this pinout in this project files here.

For my design, I had a few key decisions. The first step was to see how many of the Atomo modules I could drive using the 40-pin connector, especially since two pins are taken up by the EEPROM. I need I2C, SPI, some control pins for both of those, and 6 GPIO pins for each module. I also need some pins for handling the ADC, whatever that is. It ends up two modules is about the limit in this case for directly linking to the module IO and PWM pins along with bus connections. If I wasn't going to do ADC pins, I could do a third, but that is a bit awkward with the 2, 4, and 8 module base systems.

After some consideration, the final system level design is to use the Raspberry Pi 40-pin header to drive the shared busses and the last two of four IO module interfaces. The first two will be driven by an MCU on the adapter that is also able to work independent of the Pi in the cases that you just want a simple system.

TBC...

RPi_P1_Pinout.xlsx

This is a spreadsheet version of the pinout at https://github.com/Gadgetoid/Pinout.xyz/blob/master/src/en/template/pinout.yaml

sheet - 10.32 kB - 03/21/2017 at 13:53

Download

View file

  • Design Decisions

    Jon Buforda day ago 0 comments

      The last few days have been looking at the pin configuration of a system that ran the Pi pins directly to a module header with analog pins provided by an MCU. Not that the whole time was spent on this, but more doing some planning and then digesting the limitations of different options. It ended up to do a 4-module design, it would need a 64-pin package MCU to provide all the support (2 modules completely on the MCU and support for the other 2 modules that are mostly handled by the Pi). This starts pushing up the complexity of the design and also the cost of it, somewhere that is outside of the ideal solution space.

      So, I stepped back and considered what are the design goals. One option is to go for a 4-module design but to limit it when connected to existing connector boards (remove system pins, etc.). The problem with this is implementing a non-standard pinout of the modular controller connector kind of defeats the purpose of having a standard. The other option was to re-assess the benefits of hooking up the Pi to a system like this and see if there was some design in the middle that really put some benefits back into it over just the existing controller modules.

      The current (final) design direction for this project is this:

      1. Create a 2-IO Module compatible design that is a Raspberry Pi HAT.
      2. Instead of creating an adapter module that works as a controller module, create a combined controller-connector module that integrates an MCU that acts both as an intelligent buffer between the Pi and the IO modules as well as extends the Pi with ADC and other facilities.
      3. Keep the total retail pricing at $10, which means we want a BOM cost of something like $2.5.
      4. Use a 5V and ESD tolerant part, like the KE series to protect the Pi from things that would normally damage it.
      5. Create a powered and unpowered variant.
      6. Make sure it is compatible with extended modules, like the POE power module, since, well, that fits really well with the Pi as a network powered installation.

      Now that the design is more at a system level, it is not as important to do the pin connections first, but to look at the board level configuration. I've started with creating a full HAT sized board and put an assembly together that has the features required to look at spacing of things and to consider the overall use case. That gives us a direction to help define the system inputs and outputs which then defines the requirements of things like the MCU. OK, time to go hash that out.

  • Design and Project Decisions

    Jon Buford03/22/2017 at 07:31 0 comments

      Yesterday set up this project and filled in info to get it up to where I was at. Today started fleshing in the design decisions to get things moving further. After writing up a bunch of info for the Details Section, I think I'll use this log section for my design details and keep the high level project details to be more about the implementation of those decisions.

      1st Design Decision: How to implement ADC pins?

      So, after sorting out that the max of directly driven IO pins is two IO modules, I started looking at the overall design and usability and considered three options that I needed to research:

      1. Use an ADC IC to implement just the four ADC pins for a two IO module controller adapter.
      2. Use an MCU to implement all outstanding pins, including system pins and IO module ADC pins for a two module system.
      3. Use a slightly larger MCU to implement both all the needed pins for a two module system as well as act as an IO extender to make the controller adapter design work with up to a four IO module system.

      Coming at things from a consumer product background. On one hand, I optimize for cost, and if that was the only consideration, the most obvious solution for the above would be to use a cheap 8-bit controller to do either option 2 or 3. However, even though the cost could be closer to $0.30 USD for the controller, this would be not as accessible for most of the other users for the system who are going to be programming ARM Cortex based controllers. So, 8-bit is not really an optimal solution because it is too different from other bits of the system, and this adapter is more likely to be hacked by end users in interesting ways.

      The ADC IC would be easier to implement, but they cost about twice what even a full-featured MCU does for the same application. So, option 1 is out, unless you need specific things like paired analog readings on all pins. A fast and cheap MCU should be able to make samples and optionally do things like averaging or interrupt exceptions when a limit is hit. The basic features of reading ADC and then making it accessible via SPI or another route *should* not be too involved.

      I've been using mostly NXP Kinetis line ARM based MCUs for most of my stuff lately. They are pretty easy to source, and have good options for development tools. The STM parts would also be a consideration, they tend to be either cheaper or have better specs for similar pricing. In this case, what bubbled up are two options:

      1. Two module design with the Pi providing all GPIO and bus connections, only provide the ADC for the two modules via a MKE04Z8VTG4
      2. Four module design using a MKE02Z16VLC4 to support all ADC plus two modules of GPIO and PWM.

      The second option would be a little more expensive, the MCU is about $1 in reasonable quantities where the first option is about $0.6. But, once this is added into the cost of the overall adapter module, it would be a significantly better amount of functionality at what ends up being less than extra $2 on a retail price. The other part is that the HAT board size is larger than the two module controller board, so in order to get the full 40 pins on the HAT, plus mounting holes, we will already have enough room for the four module card edge connector (PCIe type 98-pin connector).

      So, we will be designing a HAT that has a 32-pin ARM Cortex m0 as an IO expander and that uses the Raspberry Pi pins for GPIO/PWM functions on two Atomo IO modules plus another two IO module support using the IO expander. With the design of the Atomo controller interface, we either need to put the Pi direct module connections on the first two or last two, and that will define how this can be used with or without a Pi connected.

      2nd Design Decision: Pi connects to modules 0 & 1 or 2 & 3?

      This one has a few different tradeoffs:

      1. If we put the Pi controlling the first two modules, then if we use it in a two-module setup, the system really needs the Pi to work. Only ADC pins would be available without a Pi connected.
      2. If we put the Pi...
    Read more »

  • Base Research and Initial System Design

    Jon Buford03/21/2017 at 08:55 0 comments

      Yesterday I just researched the HAT spec to understand what all is required for compatibility other than just using the pins. I then started sketching out some solutions in spreadsheets to get a feel for how the available pins might work with the Atomo Controller Module interfaces. The plan is to use something for giving the ADC capability over SPI, since the Pi doesn't have ADC.

      After looking at the ADC ICs and available MCUs, the MCU direction makes a lot more sense. It is significantly cheaper and is more flexible. There are two options that make sense:

      1. Two module design with the Pi providing all GPIO and bus connections, only provide the ADC for the two modules via a MKE04Z8VTG4
      2. Four module design using a MKE02Z16VLC4 to support all ADC plus two modules of GPIO and PWM.

      Either way, need to sort out the easiest way to communicate using what pins are available and not interfere with the current backplane design for multiplexed SPI selects.

View all 3 project logs

Enjoy this project?

Share      

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates