9

I am setting up some Raspberry Pis for use in demos to colleagues, in order to show off capabilities of the Pi itself, and of some of the add-on boards that are available.

I would really like to be able to maintain one cron-job/start-up script for all the possible demos I'm setting up, and have that script detect what HAT or older GPIO board is plugged in, so that I can trigger an appropriate demo script/program.

For example,

  • If a SenseHAT is attached, then auto-start a Sense HAT Marble Maze
  • If a Display-O-Tron HAT is attached, then auto-run the menu example
  • If a PiTFT screen is attached, then auto-start a photo slide show

Is there any way to run Python, sh or similar, to detect which of some common GPIO boards is connected to a Pi?

Things I considered:

  • Using information from Pinout.xyz to detect the pins in use, but that sounds like a lot of work.

Note that my intention is to auto-detect the configuration, without needing to attach a keyboard, ssh in, or similar - hence the wish for auto-detection, and why something like setting an environment variable wouldn't help.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
Clare Macrae
  • 275
  • 2
  • 11
  • 1
    I think this is possible with hats, since they contain an eprom used for setup. You can probably determine the rest with some shell scripting and looking at what is reported by dmesg, lsusb etc. You may also want to consider setting an environment variable that you change when you swap hardware. – Steve Robillard Dec 08 '15 at 22:53
  • @SteveRobillard, do all the hats come with an eprom? Are they not stackable? If so how are the then multiple eprom addressed separately? – Ghanima Dec 08 '15 at 23:04
  • @SteveRobillard Thank you for the suggestion. I've clarified my question to try to say why setting environment variables (and any other keyboard interaction) won't work. I hadn't heard of dmesg and lsusb. Googling them pointed me to Know your Raspberry Pi which looks good too. – Clare Macrae Dec 08 '15 at 23:04
  • @Ghanima I would be really happy to solve this for the one-HAT case, and not worrying about stacking them! – Clare Macrae Dec 08 '15 at 23:05
  • Good read: https://github.com/raspberrypi/hats – Ghanima Dec 08 '15 at 23:09
  • @SteveRobillard, I withdraw my first comment, per rpi.blog 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. – Ghanima Dec 08 '15 at 23:10

2 Answers2

5

Having read through the very helpful earlier comments and answers from Steve Robillard and Ghanima:

/proc/device-tree/hat/product

If /proc/device-tree/hat/product exists, you have a HAT attached and loaded - and that file contains the name of HAT.

Here are some sample outputs:

Display-o-Tron HAT

cat /proc/device-tree/hat/product
Display-o-Tron HAT

Names and content of all the files in /proc/device-tree/hat/ for this device:

name: hat
product: Display-o-Tron HAT
product_id: 0x0007
product_ver: 0x0001
uuid: 666dfe9b-9d78-4825-bbfe-1697048fc6cd
vendor: Pimoroni Ltd.

Adafruit PiTFT Plus - 3.5 inch

cat /proc/device-tree/hat/product
Adafruit PiTFT Plus - 3.5 inch Resistive

Names and content of all the files in /proc/device-tree/hat/ for this device:

name: hat
product: Adafruit PiTFT Plus - 3.5 inch Resistive Touch
product_id: 0x0000
product_ver: 0x0000
uuid: 684cdc28-d27f-4065-9d11-bb3f3463786d
vendor: Adafruit Industries

Update: 2018-05-17

Some devices are marketed as HATs but don't have an EEPROM with a valid data blob, in which case, there is no way to detect the "HAT" type, as it doesn't match the HAT specification.

Update: 2020-01-07

I created a github repo with a script to obtain the data for the HATs I had access to, and to record those which are not really HATs:

https://github.com/claremacrae/raspi_hat_data

Pull requests are welcome - just run the copy_hat_data.sh script in that repo.

Clare Macrae
  • 275
  • 2
  • 11
  • 1
    Glad this works well for you! Thanks for the real life contents of the device tree. It certainly helps to understand the issue better. – Ghanima Dec 09 '15 at 09:26
  • It still works! The issue you linked on github was just user error. – Paul Slocum Jan 07 '20 at 07:24
  • Thanks @PaulSlocum - I've updated this, and made the repo about this more obvious.... If you try it out on any HATs I didn't have data for, I'd really appreciate your adding it... Let me know if you need more info.... – Clare Macrae Jan 07 '20 at 11:54
  • I am getting exact same information from /sys/firmware/devicetree/base/hat if there is a hat on plugged into the RPi. Which one is recommended? – testuser Apr 19 '20 at 08:50
4

Ripping off SteveRobillards excellent comment:

Use the HAT's I2C EEPROM

The Raspberry Pi Blog points for HAT specification to GitHub where both documentation and software tools (eepromutils) for manipulation are available.

README.md:

The ID EEPROM contains data that identifies the board, tells the B+ how the GPIOs need to be set up and what hardware is on the board. This allows the add-on board to be automatically identified and set up by the Pi software at boot time including loading all the necessary drivers.

Information of the HAT is reflected in the device tree /proc/device-tree/hat that could be read from user-space in any of the mentioned ways (python, sh, ...).

Note that there are no stacked HATs* (per Raspberry Pi Blog):

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.

So at any given time only one HAT will be connected, have its EEPROM read out, and made its information available at the device tree.

* It is possible to make stackable hats if they are of the same type and thus do not require multiple and differing identification, e.g. the Adafruit 16-Channel PWM/Servo HAT for Raspberry Pi.
Ghanima
  • 15,855
  • 15
  • 61
  • 119