Andyroo wrote: ↑
Fri Mar 01, 2019 5:10 pm
thagrol wrote: ↑
Fri Mar 01, 2019 4:58 pm
If you want the autoconfigration magic to work you also need to connect the ID_SD and ID_SC pins.
This doesn't allow two HATS with eeproms. Their onboard eeproms will conflict so neither will configure corrcetly.
Never understood this, detection is via an I2C bus but its hard coded to look for address 50 - why not allow cards to have alternate addresses as normal I2C devices often have jumpers / pads to change their addresses.
Sure, but that's not the same use case.
If you allow random addresses for the eeprom you then have to probe every address on the I2C bus to see if there is a device there. Then you have to probe every device you found to see if it's an eeprom. That's before you can even attempt to read its contents.
Then how do you know which eeprom is the right one? Which order the contents of multiple eeproms should be applied in? Etc.
Those are hard problems to solve and doing so will slow boot and make things a lot more complicated.
I know some sites sell 'shims' that are very small HATs that allow stacking and you can get pHAT Stacks
- I assume these have the Eprom lines disabled / not connected?
"shim" != HAT
As for pimoroni's products, you'd have to ask them but I doubt it. I didn't see anything in the documentation that said HATs with eeproms* can only be used in a specific slot. Or that they aren't supported at all.
The one HAT at a time constraint has been around since RPF launched the HAT spec. Which, TBH, is probably what most users do anyway. Don't forget that not everything HAT shaped is actually a HAT.
* Yes, I know. If it doesn't have an eeprom it's not actually a HAT.
Attempts to contact me outside of thes forums will be ignored unless signed in triplicate, sent in, sent back, queried, lost, found, subjected to public enquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters