Posts: 2
Joined: Thu Jun 25, 2015 3:40 am

What do I gain from having an EEPROM on an add-on board?

Sat Jun 27, 2015 1:10 am


I am working on a motor driver expansion board for the Raspberry Pi, similar to this smaller board, but in the standard HAT form factor. The new board also has provision for an ID EEPROM to make it fully conform to the HAT specification, but even after looking over the specification carefully, I'm having a hard time seeing any kind of substantial benefit that the EEPROM could offer. It seems largely pointless to put one on this type of add-on board, and I want to check if I'm missing something. (The board has been prototyped and tested, and it is basically ready for production aside from the decision of whether to populate the EEPROM on the PCB.)

The HAT specification says "The purpose of this [device tree] overlay is that it allows true automatic configuration of all devices attached to the HAT, as long as there are Linux device drivers available for the hardware in question." So it seems like the device tree blob could be used for setting up things like the I2C or SPI interface and loading the correct drivers for hardware connected to those interfaces, allowing high-level access to that hardware from Linux. But the motor driver add-on is intended to be controlled through low-level direct GPIO access, so it isn't clear to me what (if anything) a device tree overlay would be useful for, or even what information it should contain.

Using the GPIO map to set up GPIO pins does not seem particularly useful in this case either. If the Raspberry Pi has to interface with the motor driver by manipulating GPIOs through a program or library, it's straightforward to have that same program or library configure the pins the way they should be set up.

Having vendor info specified in the EEPROM seems cool, but would the Raspberry Pi do anything with that information?

On the whole, then, it doesn't seem like I would be missing out on much by omitting the ID EEPROM from such an add-on board. (In fact, if the board can function without an EEPROM, adding one might only serve to cause problems stacking it with another HAT when that might otherwise work fine.) Is there something I don't understand about how the information in the EEPROM is used or some other argument in favor of having an EEPROM?

I understand that by not having an ID EEPROM, the board would not meet the HAT specification and is not supposed to be called a HAT, but that is just an issue of naming. Do (potential) users find that important?


User avatar
Posts: 15572
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: What do I gain from having an EEPROM on an add-on board?

Sat Jun 27, 2015 7:40 am

I think that mostly people would not be too worried, as long as the board worked correctly.

One possible advantage that I can see of following the HAT spec and adding an ID EEPROM (apart from being able to call it a HAT), is that the software could easily identify whether the correct board is connected before it starts driving those GPIOs. It could also take into account different revisions of the board which may need different timings, or have additional functionality.

User avatar
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

Re: What do I gain from having an EEPROM on an add-on board?

Sun Jun 28, 2015 12:16 pm

If your users need to run user space software for your board to be useful (such as a motor driver board) you can handle the pin settings in your software (as you said) and you don't really need an EEPROM.

In my case (microcontroller addon boards), an EEPROM would even limit/restrict the functionality/flexibility of the addon board so I decided against putting an EEPROM on them and not call them HATs. There are multiple use cases where I can't decide for the user what ALT function certain pins should have.

So it's up to you really. I have no idea what "calling it a HAT" does for marketing purposes, but -as @rpdom said- most people probably wouldn't (and shouldn't) be worried.
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")

Return to “HATs and other add-ons”