I am trying to stack an Automation Hat withe the Adafruit 16 channel PWM Hat. I used the stackable header from Adafruit on the PWM hat and can plug the Auto hat on top. When connected that way, the Pi will not start. Each board when connected separately works fine. There is a conflict somewhere. Any one know what it is?
Thinking that there is a conflict on the GPIO pins between the Automation Hat and the Adafruit 16 Channel PWM hat, I tried the following
Connect grounds pins 6 and 20, the +5 on Pin 2 and the +3.3 on pin 17, the SDA on pin 2 and the SCL on pin 3 using jumper wires.
I then did the I2Cdectec -y 1 command and found all of the I2C address’s i.e 40 and 70 for the Adafruit Hat and 48 for the Automation Hat.
Then I used the test programs for both and got good response from both Hats. Now waiting for comments on which other pins may be causing the conflict
As far as I know, a GPIO conflict shouldn’t prevent the Pi from Booting Up. Your hardware on top will have issues but the Pi should boot up.
One thing about the official hat standard is you can only use one Hat. From what I’ve read that only really applies if more than one hat has an ID eprom.I’m not sure what happens if the situation happens though. One would think it would still boot up.
What model Pi are you using? And what power supply, current rating etc.
I am using a RPi 3 with a 4 amp power supply. You made the claim that you can use only one hat per the spec. Where can i find a copy? Adafruit and others talk about many hats stacked on top of the Pi.
The ID eprom poses an interesting question. If the Pi software during boot looks at some of the GPIO pins to determine what hats are present, then i can see possible conflicts.
It appears that the Automation hat uses the ID over the I2C pins as the Pi and software do detect it correctly. I was able to control the relays, Analog and in and out ports on the Automation hat with only the terminals on it and the power and I2C pins connected with jumper wires. The Servo hat also works when connected this way.
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.
Not all Hats have the ID eeprom though. The Pi foundation Hats like the Sense Hat do, but I think you’ll find most other don’t have the eeprom. I mentioned it as something to rule out as an issue, and just in case you weren’t aware it existed…
EDIT: In short, if your hats have no ID eeproms, you can stack as many as you want, assuming they don’t conflict with each other. And any “one” of them can have the ID eeprom. It’s only an issue if there are two ID eeproms. And even then, I think you can manually set them up to work. The issue is the PI can’t address the ID’s separately, it will read one ID that doesn’t match either HAT. Thats how I read it anyway.
This problem appears to be caused by the ID_SD (pin 27) and ID_SC (pin 28) signals. My solution was to use an extension header and clip pins 27 and 28 and insert the Automation hat into it. Now the servo hat and the Automation hat execute their example programs flawlessly.
Cool, glad everything worked out for you. Thumbs up.
I pushed the two pins out of the header and then will solder it into another hat that i have and hope this works.
Just curious as to what actually happens on boot up? Does the status LED on the Pi flash at all? Anything on your monitor, boot messages etc? Just for future reference.
The green LED blinks a little, then the rainbow screen appears on the monitor until you pull the plug.
When i power up the RPI with both Hat’s only the multicolored HDMI screen comes up with no text behind it. The Red led on the RPi comes on but the green LED never Flashes. Was told that pins 27 and 28 read data from an EPROM if it is present.
Ok, thanks guys. I somehow missed there were two different people replying, ops.