Pi B+ ID EEPROM: Multiple HATs, multiple EEPROMs?

[technix]

After reading the HAT spec, I found one problem with the ID EEPROM: only one HAT can be present at any time due to address confliction. I am suggesting that instead of hardcoding the 0x50 I2C slave address, the firmware should be able to detect EEPROM chips in the full I2C address range and load all of them, so that HATs can be stacked more easily by allowing multiple ID EEPROM addresses present. This will also allow using of paged EEPROM chips by presenting one HAT as two or more stacked units to the system, as it may be preferred in some situations (e.g. the connecting the Arduino Ethernet Shield to the Pi which should be considered the SPI-based Ethernet module and an SPI-mounted SD card, as two separate devices).

[RaTTuS]

http://www.raspberrypi.org/forums/viewforum.php?f=100 this forum

[technix]

http://www.raspberrypi.org/forums/viewforum.php?f=100 this forum

This post regards the entire HAT mechanism and maybe the entire ID EEPROM system, not any specific HAT.

[RaTTuS]

yes but that forum would be better as it may just get buried here

[FLYFISH TECHNOLOGIES]

Hi,

After reading the HAT spec, I found one problem with the ID EEPROM: only one HAT can be present at any time due to address confliction.

This is not the only reason that a single HAT is supported... actually, it is other way around -> non-stackable limit was defined in order to prevent signal conflicts (eg. when two stacked boards would use the same GPIO pin). Consequently, no need to support multiple ID EEPROMs and this address can be fixed.

By supporting multiple EEPROMs you'd not solve the potential I/O signals conflicts, and it would cause nothing but some confusion.

It would make sense to support multiple ID EEPROMs only if the HAT spec would require that each board could be disabled somehow. Then the RasPi would query one board/ID EEPROM after another and in case there is a GPIO pin conflict of currently queried board with a previous one, it would get disabled. A huge drawback is that such HAT boards would require quite some more firmware and hardware logic (re$$$ulting in development effort)... not to mention neverending explanations to users about the behavior..


Best wishes, Ivan Zilic.

[gregeric]

Simple, manual scheme for stacking two boards:

Connect HAT1, boot & take copy of eeprom.
Repeat for HAT2.

Have some utility attempt to merge eeprom contents, advising of any gpio conflicts. If none exist, write new combined gpio requirements to bottom board's eeprom.

Now, if the bottom board's pass-through stacking header omits the two ic2-0 pins, only the lower combined eeprom will be read, with full gpio config requirements for both boards.

Might that scheme work?

[mahjongg]

Simple, manual scheme for stacking two boards:

Connect HAT1, boot & take copy of eeprom.
Repeat for HAT2.

Have some utility attempt to merge eeprom contents, advising of any gpio conflicts. If none exist, write new combined gpio requirements to bottom board's eeprom.

Now, if the bottom board's pass-through stacking header omits the two ic2-0 pins, only the lower combined eeprom will be read, with full gpio config requirements for both boards.

Might that scheme work?

No! Far to complex and uses a lot of user interaction, you might as well ask the user to put different arrangement of jumpers on the three bit I2C EEPROM address of each board to add multiple devices to the I2C bus. And alas, I can think of no method to automatically detect the stacking order, if all the header pins are simply paralleled.

The physical design of the 40-pin header is already fixed, and will thus not support any "daisy chain" arrangement, so IMHO stacking of the HAT boards themselves will NOT be supported, but you are free to design your own stacking mechanism on top of a regular HAT, and use the normal I2C bus for EEPROM's, I like to call such boards TOP's.

And If you add a "daisy chain" mechanism with a signal that senses at which "hop" of the daisy chain a board is, you could use that "hop number" (or "floor level code", as I like to call it) with a priority decoder to create a 3-bit address for I2C devices.
I mean, lets say you have seven female "underside" headers, and seven male "upper side" headers, and each board loops each pin of an underside header through to the next pin of the upper side header, (thus creating a chain that runs from pin 1 of the lowest board (of seven) to pin 7 of the highest board) pin 1 of the lowest board (the HAT) is connected to GND, so each next stacked board will have one more pin in the chain connected to GND, the first stacked board (TOP) only has pin 1 connected to GND, but not pins 2 to 7, and the second TOP has pin 1 and pin 2 connect to GND, etc etc. The detection mechanism can then detect the latest pin in the chain that is still connected to GND, and with the use of a priority decoder it can create a 3-bit binary number between 0 and 7 which becomes the I2C device address. Binary number 0 (or seven) can be assigned to the HAT, that supports up to seven TOP's.

[technix]

Some HATs are stackable so this HAT stacking may be beneficial: I2C-based HATs like an HD44780 driver based on a I2C GPIO expander like NXP PCF8574 (I have one,) an RTC HAT based on NXP PCF8563 or Dallas DS1338, or another EEPROM device; 1-Wire based HATs like a temperature sensor based on Dallas DS18B20 or those iButtons; or up to 5 SPI-based HATs like LCM12864 LCD module or Maxim MAX72xx LED matrix.

Another situation is that one HAT can make more sense if presented to the Pi as two stacked HATs of the functionality is clearly different: for example if we HAT-ify the Arduino Xbee module, the SD card and the Xbee wireless module makes more sense to be presented as different HATs.

[AndrewS]

Some HATs are stackable...

Nope. The HAT specification says they're non-stackable; you're free to design boards to be stackable, you simply can't call them HAT boards.

[technix]

Hi,

After reading the HAT spec, I found one problem with the ID EEPROM: only one HAT can be present at any time due to address confliction.

This is not the only reason that a single HAT is supported... actually, it is other way around -> non-stackable limit was defined in order to prevent signal conflicts (eg. when two stacked boards would use the same GPIO pin). Consequently, no need to support multiple ID EEPROMs and this address can be fixed.

By supporting multiple EEPROMs you'd not solve the potential I/O signals conflicts, and it would cause nothing but some confusion.

It would make sense to support multiple ID EEPROMs only if the HAT spec would require that each board could be disabled somehow. Then the RasPi would query one board/ID EEPROM after another and in case there is a GPIO pin conflict of currently queried board with a previous one, it would get disabled. A huge drawback is that such HAT boards would require quite some more firmware and hardware logic (re$$$ulting in development effort)... not to mention neverending explanations to users about the behavior..


Best wishes, Ivan Zilic.

About that, the ID EEPROM device can be something other than EEPROM, like an Atmel ATmega168 that emits both HAT info like an EEPROM and (internally) a ready signal when interrogated. We just need to release a demo Arduino sketch for that.

[technix]

Simple, manual scheme for stacking two boards:

Connect HAT1, boot & take copy of eeprom.
Repeat for HAT2.

Have some utility attempt to merge eeprom contents, advising of any gpio conflicts. If none exist, write new combined gpio requirements to bottom board's eeprom.

Now, if the bottom board's pass-through stacking header omits the two ic2-0 pins, only the lower combined eeprom will be read, with full gpio config requirements for both boards.

Might that scheme work?

No! Far to complex and uses a lot of user interaction, you might as well ask the user to put different arrangement of jumpers on the three bit I2C EEPROM address of each board to add multiple devices to the I2C bus. And alas, I can think of no method to automatically detect the stacking order, if all the header pins are simply paralleled.

The physical design of the 40-pin header is already fixed, and will thus not support any "daisy chain" arrangement, so IMHO stacking of the HAT boards themselves will NOT be supported, but you are free to design your own stacking mechanism on top of a regular HAT, and use the normal I2C bus for EEPROM's, I like to call such boards TOP's.

And If you add a "daisy chain" mechanism with a signal that senses at which "hop" of the daisy chain a board is, you could use that "hop number" (or "floor level code", as I like to call it) with a priority decoder to create a 3-bit address for I2C devices.
I mean, lets say you have seven female "underside" headers, and seven male "upper side" headers, and each board loops each pin of an underside header through to the next pin of the upper side header, (thus creating a chain that runs from pin 1 of the lowest board (of seven) to pin 7 of the highest board) pin 1 of the lowest board (the HAT) is connected to GND, so each next stacked board will have one more pin in the chain connected to GND, the first stacked board (TOP) only has pin 1 connected to GND, but not pins 2 to 7, and the second TOP has pin 1 and pin 2 connect to GND, etc etc. The detection mechanism can then detect the latest pin in the chain that is still connected to GND, and with the use of a priority decoder it can create a 3-bit binary number between 0 and 7 which becomes the I2C device address. Binary number 0 (or seven) can be assigned to the HAT, that supports up to seven TOP's.

I think I have one, but that requires using ATmega168's instead of simple EEPROMs as the ID devices. When the boards are powered, the ATmega168's start to detect the I2C bus and settle down on different addresses automatically. Multiple mechanisms exist, and the SMBus mechanism is far most common.

[technix]

Some HATs are stackable...

Nope. The HAT specification says they're non-stackable; you're free to design boards to be stackable, you simply can't call them HAT boards.

Some board designs can be fully compatible with HAT spec when used in solo, but also stackable. What do you call them?

[rpdom]

Some HATs are stackable...

Nope. The HAT specification says they're non-stackable; you're free to design boards to be stackable, you simply can't call them HAT boards.

Some board designs can be fully compatible with HAT spec when used in solo, but also stackable. What do you call them?

You can call them anything you like - except HATs.

[mahjongg]

TOP-HATS perhaps?

[technix]

TOP-HATS perhaps?

Haha. I have written a simple TOP spec which is designed to be fully compatible with HATs when used in solo. I have 2 solutions present, the 48-pin TOP which uses pins and priority encoder to set the address (like you suggested, but without a base board), and a 40-pin one that uses microcontrollers in place of ID EEPROMs and talk SMBus to automatically assign themselves addresses.

[mahjongg]

wouldn't be the "base board" simply be the equivalent to a normal HAT board, or how do you let the board "know" its the lowest board of the stack, when all boards have an identical setup (as that what I think you mean by "without a base board")?

sounds great BTW.

[technix]

wouldn't be the "base board" simply be the equivalent to a normal HAT board, or how do you let the board "know" its the lowest board of the stack, when all boards have an identical setup (as that what I think you mean by "without a base board")?

sounds great BTW.

Just read my separate post, it is achieved by using pull-ups and grounded pins, as well as a staggered connection. The bottom board have only 1 pin grounded, the second have 2 pins grounded, and so on.

[mahjongg]

wouldn't be the "base board" simply be the equivalent to a normal HAT board, or how do you let the board "know" its the lowest board of the stack, when all boards have an identical setup (as that what I think you mean by "without a base board")?

sounds great BTW.

Just read my separate post, it is achieved by using pull-ups and grounded pins, as well as a staggered connection. The bottom board have only 1 pin grounded, the second have 2 pins grounded, and so on.

did you adopt my "daisy chain" mechanism for letting each TOP detect the "floor level" (stacking order) it is on?
Then you would now that the "bottom TOP" (a bit of a contradictory term, i know) needs to short the first stage of the daisy chain to GND, so that each level has one more stage of the chain pulled down from its own pull-up. Alternatively the first stage can be tied to 3V3, and each levels has a pull down instead, if that is more logical for the priority decoder, but for this example i follow the first stratagem.

Like this (an & means a "staggered" loop through) for a "bottom board" with three TOP's:

GND &----(pin 1) pullup level 1 ---- & --- (pin 2) pull-up level 2 --- & --- (pin 3) pull-up level 3 (and this is the top board so no further staggered loop throughs follow)

the floor level 3 board will have pin 1, 2 and 3 tied to GND, but not levels 4 and up
the floor level 2 board will have pin 1 and 2 tied to GND but not levels 3 and up
the floor level 1 board will have pin 1 tied to GND, but not levels 2 and up
the floor level 0 board simply "knows" its the "base board", and gets the code "000"

With a CD74HC147M "priority encoder" you can use this information to create a 3-bit code that corresponds to its "floor level", the 3-bit "floor level code" can be used in all cases where a differentiation must be made between multiple I/O devices on the same (I2C or SMbus) bus or I/O pin.

Yes, I/O pin! Another idea is to assign 8 (or 16) GPIO pins, and assign one (or two) of them to each board, by using 8-to-1 analog multiplexers (74HC4051 style) with their address select inputs controlled by the 3-bit floor code, that way each board can have 1 or 2 GPIO's uniquely assigned to it, for, for example, interrupts. The one COM OUT/IN pin of a 4051 (pin 3) is connected to the driving IRQ source (for example) of a board, and the eight Ax pins are connected to the eight assigned GPIO pins.

[technix]

wouldn't be the "base board" simply be the equivalent to a normal HAT board, or how do you let the board "know" its the lowest board of the stack, when all boards have an identical setup (as that what I think you mean by "without a base board")?

sounds great BTW.

Just read my separate post, it is achieved by using pull-ups and grounded pins, as well as a staggered connection. The bottom board have only 1 pin grounded, the second have 2 pins grounded, and so on.

did you adopt my "daisy chain" mechanism for letting each TOP detect the "floor level" (stacking order) it is on?
Then you would now that the "bottom TOP" (a bit of a contradictory term, i know) needs to short the first stage of the daisy chain to GND, so that each level has one more stage of the chain pulled down from its own pull-up. Alternatively the first stage can be tied to 3V3, and each levels has a pull down instead, if that is more logical for the priority decoder, but for this example i follow the first stratagem.

Like this (an & means a "staggered" loop through) for a "bottom board" with three TOP's:

GND &----(pin 1) pullup level 1 ---- & --- (pin 2) pull-up level 2 --- & --- (pin 3) pull-up level 3 (and this is the top board so no further staggered loop throughs follow)

the floor level 3 board will have pin 1, 2 and 3 tied to GND, but not levels 4 and up
the floor level 2 board will have pin 1 and 2 tied to GND but not levels 3 and up
the floor level 1 board will have pin 1 tied to GND, but not levels 2 and up
the floor level 0 board simply "knows" its the "base board", and gets the code "000"

With a CD74HC147M "priority encoder" you can use this information to create a 3-bit code that corresponds to its "floor level", the 3-bit "floor level code" can be used in all cases where a differentiation must be made between multiple I/O devices on the same (I2C or SMbus) bus or I/O pin.

Yes, I/O pin! Another idea is to assign 8 (or 16) GPIO pins, and assign one (or two) of them to each board, by using 8-to-1 analog multiplexers (74HC4051 style) with their address select inputs controlled by the 3-bit floor code, that way each board can have 1 or 2 GPIO's uniquely assigned to it, for, for example, interrupts. The one COM OUT/IN pin of a 4051 (pin 3) is connected to the driving IRQ source (for example) of a board, and the eight Ax pins are connected to the eight assigned GPIO pins.

My mechanism design is pretty similar with that, just red my posts.

I/O pin is not allow to be used or the configuration mechanism will depend on it and call for a microcontroller ID device, but with that whatever you are using I/O pins for can be done without using I/Os except an interrupt pin.

[mahjongg]

I've read all your relevant posts (not all 55 of them, but all those about HAT's and TOP's), but forgive me, but I can't find anything that explains what you wrote here:

it is achieved by using pull-ups and grounded pins, as well as a staggered connection. The bottom board have only 1 pin grounded, the second have 2 pins grounded, and so on.

and

which uses pins and priority encoder to set the address (like you suggested, but without a base board),

Without a base board, how are you grounding the start of the daisy chain? Or do you have a completely different mechanism in mind than daisy chaining using staggered pins? The daisy chain method requires that there is a first board that ties the start of the chain low (or high), so what do you mean by "without a base board"?

Also, you are talking about using a micro controller to emulate the EEPROM's, because you want more than one EEPROM on the same I2C bus, but EEPROMs already have a mechanism to do that using three address pins, of which a HAT has all three tied low, the TOP boards can use the three bits from the priority encoder to set 001, 010 etc up-to 111.

[technix]

I've read all your relevant posts (not all 55 of them, but all those about HAT's and TOP's), but forgive me, but I can't find anything that explains what you wrote here:

it is achieved by using pull-ups and grounded pins, as well as a staggered connection. The bottom board have only 1 pin grounded, the second have 2 pins grounded, and so on.

and

which uses pins and priority encoder to set the address (like you suggested, but without a base board),

Without a base board, how are you grounding the start of the daisy chain? Or do you have a completely different mechanism in mind than daisy chaining using staggered pins? The daisy chain method requires that there is a first board that ties the start of the chain low (or high), so what do you mean by "without a base board"?

Also, you are talking about using a micro controller to emulate the EEPROM's, because you want more than one EEPROM on the same I2C bus, but EEPROMs already have a mechanism to do that using three address pins, of which a HAT has all three tied low, the TOP boards can use the three bits from the priority encoder to set 001, 010 etc up-to 111.

Read through http://www.raspberrypi.org/forums/viewt ... 00&t=86039 very carefully, maybe scribble a bit about how stuff looked like when TOPs is stacked, and you will see. In a nutshell, chains runs parallel so every 48-pin TOP can function as a base board.

The EEPROM simulating micro controller is required when the devices talk SMBus as no standard EEPROM device supports the address assigning protocol SMBus is using. SMBus is more than I2C as there is a mechanism to negotiate addresses.

[sijmen]

Some HATs are stackable...

Nope. The HAT specification says they're non-stackable; you're free to design boards to be stackable, you simply can't call them HAT boards.

I've been trying to find this in the spec. Where does it say that a HAT cannot be stackable?

Regards.

[ghans]

Perhaps AndrewS is thinking of this :
viewtopic.php?f=100&t=85786#p606039
https://github.com/raspberrypi/hats/issues/16

ghans

[sijmen]

Perhaps AndrewS is thinking of this :
viewtopic.php?f=100&t=85786#p606039
https://github.com/raspberrypi/hats/issues/16

Thanks ghans,
Still I can't find anything definitive in those links. Mostly it seems the assumption is that they should not be stackable, primarily because of the issue of multiple HATS sharing the same GPIO pins. Lets say I don't use the GPIO pins. Can my addon board be stackable and still called a HAT?

[hippy]

The spec implicitly excludes stacking.

https://github.com/raspberrypi/hats

"It has a valid ID EEPROM (including vendor info, GPIO map and valid device tree information)"

As there can't be two valid ID EEPROM - to be valid they would each need the same address - they can't be stacked.

But it doesn't really matter. You can actually do whatever you want, just that the Foundation and probably everyone else in the Pi community would prefer that you did not call it a HAT.