Pi support for different simultaneous HATs over i2c?

[gearjammer_6spd]

Hi All,

I'm trying to get two HATs working in "stacked" mode on my Pi. The two hats are: DC motor HAT from Adafruit and the new Pi Sense HAT from RaspberryPi.org.

So far I have the motor hat working over I2C and all is ok. I've now stacked the Pi Sense on top and not having much luck.

This is my setup (in order of stacking)
Pi with 5v 2A power supply
DC motor hat (no external power for motors at the moment and no motors)
Pi Sense hat on top

When I run i2cdetect, I get a number of addresses including x060 which I used to use for the motor HAT and seems unchanged.
However when I use the sense_hat library in python, I'm getting a bunch of errors.

Ipi@kcpi ~ $ ls /dev/i2c*
gives me
/dev/i2c-1

My questions are:
1) Can Pi support different simultaneous HATs over i2c?
2) Is there something wrong with my setup?

Any help is much appreciated!

Thanks!

[gearjammer_6spd]

Sorry I forgot to add this:

My Pi is a model B+ (Raspberry Pi 2 Model B v1.1)

I see from the docs that the EEPROM reading is now implemented.

[GerardWassink]

Using different kinds of HAT's should not be any problem as long as they do not use the same I2C addresses. Does the sense HAT not need an external power supply?

[PeterO]

I thought stacking HATs was not supported by the HAT spec ?
PeterO

[GerardWassink]

As far as I know, the Adafruit servo HAT is stackable. They state one can stack up to 62 of them, theoretically. That's why I presumed it is possible.

[PeterO]

Is it actually a HAT because on https://www.raspberrypi.org/blog/introd ... y-pi-hats/ jdb said:

31st Jul 2014 at 1:08 pm
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.
Stacking is implicitly not supported for HATs, but you can design non-HAT stacking boards using the example surface-mount connector scheme.

PeterO

[BMS Doug]

I don't think the DC motor HAT truly is a HAT (It is), it has an i2c chip (connected to pins 3 & 5) but no hat EEPROM (it does have an EEPROM). the only reason for this to clash with the AstroPi HAT is if the i2c address clashes with one that the AstroPI HAT is using.

If connecting the Hat off-the Pi via jumpers, you will need to connect GND and 3.3v in addition to SDA and SCL.

connect just the Astro Pi HAT and collect the addresses used on the i2c busses, repeat with just the DC motor HAT (Should be 0x60 unless you have changed it), look for clashes.


For those interested the Motor Hat is a PCA9685 (16-channel, 12-bit PWM Fm+ I2C-bus LED controller) which is sending signals to a pair of TB6612 (1.2A Dual H-Brdige) Motor Driver chips.
And a CAT24C32 (32-Kb I2C CMOS Serial EEPROM) with the Write Protect able to be shorted to 0V by a solder bridge on the face of the HAT (whicha would enable writing to the ID EEPROM).

[GerardWassink]

I am currently developing a 16 relay I2C board based on the MCP23017 chip and two ULN2308's. See the doc library for spec's of those parts.

I know, it's probably been done dozens of times, but I wanted to try anyway.

For this project, the decoder/driver board is fed using a 5Volt PSU. I only connect GND, SDA and SCL from the RPi, while the Adafruit servo HAT is also connected.

Strictly speaking this does not qualify as "stacking" of course... But hey, it works...

[BMS Doug]

I am currently developing a 16 relay I2C board based on the MCP23017 chip and two ULN2308's. See the doc library for spec's of those parts.

I know, it's probably been done dozens of times, but I wanted to try anyway.

For this project, the decoder/driver board is fed using a 5Volt PSU. I only connect GND, SDA and SCL from the RPi, while the Adafruit servo HAT is also connected.

Strictly speaking this does not qualify as "stacking" of course... But hey, it works...

I'd say it qualifies as "stacking" it just doesn't technically qualify as a HAT (neither does the Adafruit Motor HAT) as it doesn't have an ID EEPROM.

an ID EEPROM would only add cost and no real extra functionality so I 'd rather omit it.

I have seen other i2c based 16 channel relay boards (but they are hard to find), it's a convenient solution to a common problem.

[GerardWassink]

I'd say it qualifies as "stacking" it just doesn't technically qualify as a HAT (neither does the Adafruit Motor HAT) as it doesn't have an ID EEPROM.

That's true... I didn't make that distinction.

I have seen other i2c based 16 channel relay boards (but they are hard to find), it's a convenient solution to a common problem.

When you guys like, I can of course post my schematics.

[GerardWassink]

My process of development (not quite finished yet) can be followed at my youtube channel.
Film 56 shows my attempts while I was still working with transistors.
Film 57 shows the ULN2803 relay drivers.
Film 58 shows the first prototype decoder/driver board.

[gearjammer_6spd]

Hi Gerard, Doug, PeterO,

Thanks for the feedback. you're right - the dc motor hat can be cloned and stacked with different hard coded i2c addresses. I ran each board individually -looks like motor hat is default x60 and pi sense uses a different address. I'm not sure it's in conflict afaik.

A close look at the pi sense circuits tells me it might be using gpio along with i2c? Maybe the motor hat shares a gpio pin? I'm not an expert so any help is appreciated. Do you think I can drive the motor hat unstacked - with just i2c and like you said 3.3v - what would the wiring involve?

Thanks!

[BMS Doug]

Hi Gerard, Doug, PeterO,

Thanks for the feedback. you're right - the dc motor hat can be cloned and stacked with different hard coded i2c addresses. I ran each board individually -looks like motor hat is default x60 and pi sense uses a different address. I'm not sure it's in conflict afaik.

A close look at the pi sense circuits tells me it might be using gpio along with i2c? Maybe the motor hat shares a gpio pin? I'm not an expert so any help is appreciated. Do you think I can drive the motor hat unstacked - with just i2c and like you said 3.3v - what would the wiring involve?

Thanks!

I'm wrong, it does have an ID EEPROM, I can see the trace from the pins when i look at the pictures on Adafruit's site.

picture of the board


Connect Pins on Pi or (sense HAT) to corresponding pins on the motor HAT:
Pin 1 - 3V3
Pin 6 - Gnd
Pin 3 - SDA
Pin 5 - SCL

Or break the traces on the adafruit motor HAT from Pins 27 & 28 to the 8 pin SMD chip (which must be the ID EEPROM).

[gearjammer_6spd]

Thanks Doug, I'll try that out. I've screengrabbed and attached the various i2c address states for my setup:

Pi with Sense only
Pi with Motor Hat only
Pi with Motor Hat and Sense

The only thing I see when both Sense and Motor Hat are connected - is on Row 60 - There are two addresses one at col "0" - x60 and col "a" - x6a which look like different addresses to me? Is this considered a conflict?

[GerardWassink]

The only thing I see when both Sense and Motor Hat are connected - is on Row 60 - There are two addresses one at col "0" - x60 and col "a" - x6a which look like different addresses to me? Is this considered a conflict?

No it is not. This is a space-saving way to represent a large number of different addresses. For my Relay-board, on which I did built a DIP switch to be able to set it to different addresses, I can have it appear in the range from 0x20 to 0x27.

And at every one of those positions, all of it's 16 relays work.

PS: the pictures you embedded are not at all readable to me. Also they are not clickable to enlarge them. It could be my browser (OS X Safari) of course, but I thought I's let you know.

[BMS Doug]

PS: the pictures you embedded are not at all readable to me. Also they are not clickable to enlarge them. It could be my browser (OS X Safari) of course, but I thought I's let you know.

He's attached the pictures to the post which means they have to fit the forum requirements for image size. If you expand the image it remains unreadable as the resolution will never give a clear image.

You need to post the images to an image hosting website and put the link to the image within [img][/img] tags.

[PiGraham]

Thanks Doug, I'll try that out. I've screengrabbed and attached the various i2c address states for my setup:

Pi with Sense only
Pi with Motor Hat only
Pi with Motor Hat and Sense

The only thing I see when both Sense and Motor Hat are connected - is on Row 60 - There are two addresses one at col "0" - x60 and col "a" - x6a which look like different addresses to me? Is this considered a conflict?

Looking at your image it seems all i2c devices for both HATs show up in the image labelled "Pi with Sense and Motor Hat".
60 70 from motor HAT and 1c, 5c, 5f 6a from Sense HAT.

[gearjammer_6spd]

Hmmm unfortunate that the images are not readable - sorry! Ill re-post them tonight.

@PiGraham - I agree that it looks like all I2C devices are appearing and not in conflict. When I implement the sense_hat class in python - I get a bunch of errors - Note: I don't have the exact error right now - but its something like : IO Error - Cannot find %s device, SENSE_HAT_FB_NAME.

Looking at this in the source -

def _get_fb_device(self):
"""
Internal. Finds the correct frame buffer device for the sense HAT
and returns its /dev name.
"""

device = None

for fb in glob.glob('/sys/class/graphics/fb*'):
name_file = os.path.join(fb, 'name')
if os.path.isfile(name_file):
with open(name_file, 'r') as f:
name = f.read()
if name.strip() == self.SENSE_HAT_FB_NAME:
fb_device = fb.replace(os.path.dirname(fb), '/dev')
if os.path.exists(fb_device):
device = fb_device
break

return device

It could be that a framebuffer device is not being found - but this does not happen when the Pi Sense is stacked without the Motor hat. Any way I can test from a CLI tool if communications is possible with both the HATS?

Thanks for all the help!

The sense hat code looks like this:

https://github.com/RPi-Distro/python-se ... nse_hat.py

class SenseHat(object):

SENSE_HAT_FB_NAME = 'RPi-Sense FB'
SENSE_HAT_FB_FBIOGET_GAMMA = 61696
SENSE_HAT_FB_FBIOSET_GAMMA = 61697
SENSE_HAT_FB_FBIORESET_GAMMA = 61698
SENSE_HAT_FB_GAMMA_DEFAULT = 0
SENSE_HAT_FB_GAMMA_LOW = 1
SENSE_HAT_FB_GAMMA_USER = 2
SETTINGS_HOME_PATH = '.config/sense_hat'

[BMS Doug]

Hmmm unfortunate that the images are not readable - sorry! Ill re-post them tonight.

@PiGraham - I agree that it looks like all I2C devices are appearing and not in conflict.

Yes, Sorry to lead you down the wrong trail.

I was incorrect to say that the Adafruit motor HAT doesn't have an ID EEPROM, it does and that is very likely to be the source of the conflict.

If you can connect the sense HAT and use just the i2c bus (and 3V3 and Gnd) to connect the Motor HAT does it work?

If it does work with just i2c communication to the Motor HAT then the problem is with the ID EEPROMs clashing. The HAT spec says that only one ID EEPROM should ever be present (only one HAT allowed) and the Sense HAT may rigorously apply that ruling (even though the Adafruit HAT allows stacking).

If the ID EEPROMS are clashing you can probably disconnect the ID EEPROM from the motor HAT (either de-solder it from the board or simply cut the traces from GPIO pins 27 & 28).

[6by9]

If they are both genuine HATs and include a properly programmed ID EEPROM with device tree info, then having two is going to cause I2C issues on I2C-0, and you'll end up missing the DT config for the device. That would probably explain the lack of /dev/RPi-Sense FB

Enable I2C-0 in config.txt and try i2c-detect -y 0 to see what devices are seen there.

*edit* message overlap with BMS Doug. We've obviously both had the same thought.

[BMS Doug]

If they are both genuine HATs and include a properly programmed ID EEPROM with device tree info, then having two is going to cause I2C issues on I2C-0, and you'll end up missing the DT config for the device. That would probably explain the lack of /dev/RPi-Sense FB

Enable I2C-0 in config.txt and try i2c-detect -y 0 to see what devices are seen there.

*edit* message overlap with BMS Doug. We've obviously both had the same thought.

I had previously said that the Adafruit motor HAT did not have an ID EEPROM, but if you examine the image it clearly does.

You can see the traces leading from Pins 27 & 28 to the ID EEPROM.



(ID EEPROM traces are visible between the prototyping area and the power area (5V, 3V3 Gnd Rails)).

[GerardWassink]

Just for my information and curiosity: what does such an ID EEPROM do?

[edit]
Oops, never mind, found it... [blushes]

[BMS Doug]

Just for my information and curiosity: what does such an ID EEPROM do?

[edit]
Oops, never mind, found it... [blushes]

To save an other curious folk from having to follow the links I will summarise:

Essential the ID EEPROM is an i2c based memory chip that contains setting parameters for the HAT, the information is loaded from the EEPROM on startup.

[PiGraham]

The ID EEPROMs will be at the same address on that i2c bus so any code that tries to read them will fail if HATS are stacked. HATS are not designed o be stacked.

You may be able to use the resources on the HATs by addressing them directly and ignoring the ID. The error you report relates to reading the EEPROM.

[GerardWassink]

HATS are not designed o be stacked.

I beg to differ. Quote from this Adafruit page:

What's more, you can stack up to 62 of them to control up to 992 servos

.