Close

Design and Project Decisions

A project log for Designing a Raspberry Pi HAT

How to design your own HAT module including ID EEPROM.

jon-bufordJon Buford 03/22/2017 at 07:310 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 controlling the last two modules, then if we use it in a two-module setup, then we could program the expansion MCU to work without having a RPi there, but to access the Pi GPIO pins, you would have to use a four-module connector board.

With decisions like this, there are not always clear answers. On one hand, if this is a Raspberry Pi adapter first, it would make sense to give priority to having the RPi pins available in all common use cases. But, if we look at this now as a dual function board of a low-cost controller module plus support for direct Raspberry Pi HAT functionality, it would make just as much sense to prioritize the usage without the Pi installed. Since in both cases, the Pi would be connected to I2C and SPI as well as being able to control the other pins, it is probably better to make it function without the Pi on the two-module connector setup. From a functionality standpoint, there is less tradeoff this way, and it would make it more useful as a standalone module at the same time.

OK, so I need to reassign the module pins and look at how the expansion MCU needs to be included in everything to make the best of it.

Discussions