Sense Hat Pins

[ghost]

To make all the sensors work on the Sense Hat, you need the pins 27 and 28.

[lurch]

Yeah, they're the i2c pins for the EEPROM, which the Pi uses to identify the HAT.

@Gadgetoid / @RogueM Perhaps if a HAT uses the EEPROM pins, they could be coloured with a dark-blue-blob, like the used-ground-pins are currently? (which would differentiate them as 'used by EEPROM'; as opposed to 'used as GPIO' like the DOTS HAT does)

[Gadgetoid]

The pedant in me wants to say "It's not a HAT unless it uses the EEPROM pins" but I get the idea ;)

I think this could be useful for HATs, specially because pHATs don't use an EEPROM and @RogueM has gone to lengths to test and start putting together code to allow the second i2c bus to drive another pHAT where it uses i2c devices. Knowing where those pins are free would be worthwhile!

[RogueM]

all overlays should have a 'eeprom' tag, so that could be used whichever way you like. I don't think they should be listed in the pin array though. They are certainly NOT required for operation, neither on the sense HAT* nor any add-ons with eeprom (which would make them HAT by technical specifications).

But sure, I have had in mind to make use of the 'eeprom' field visually, at some point, a light blue tint or something.

*admittedly I haven't tried the sense HAT specifically, but those pins are probed at boot time only, they should have no function when the system is booted, otherwise Pi3 and RFP touchscreen users would be in no end of trouble).

[RogueM]

Incidentally, there is code in the html generator that was intended to display the eeprom info in the details section... I botched that job at the time as they don't show up though, I need to have another look, independently of whatever visual representation on the pinout might be desirable (well, I'd strongly oppose to treat them as other used GPIO, for the reason we've stated earlier).

[lurch]

The pedant in me wants to say "It's not a HAT unless it uses the EEPROM pins" but I get the idea ;)

I totally agree 👍 But the labelling "form factor" on the website implies it's just referring to the physical size, and not whether it meets the rest of the HAT specifications? But then DOTS is listed on http://pinout.xyz/boards#formFactor=Custom
Hmmm...

@RogueM I believe that the EEPROM is probed at boot-time on the Sense HAT, and that then loads a bit of extra info into the DeviceTree, which the booting kernel detects, and uses to load extra modules. So technically the EEPROM pins aren't required for operation, but without them you'll need to know what extra kernel modules to manually modprobe. See raspberrypi/documentation#326 for some more background info.

[RogueM]

Just to clarify for the OP, the EEPROM enables i2c bus (i2c1, on phys pin 3 and 5) at boot time when a sense HAT is fitted, but you can enable it manually (permanently). You are correct however that it won't work if you skip that step.

[RogueM]

cheers @lurch, I'll check it out. Still, I'm fairly sure you can get a sense HAT working without connecting pin27 and 28 though (with ad hoc configuration)? I'll have to try it out for myself.

Either way, if it makes pinout users life a lot simpler listing them as required, whatever definition we attach to that word, I'm fine adding them.

[RogueM]

I had a look at that topic, as well as (a refresh) on the HAT eeprom doc.

Basically, the flashing process includes the dt blob on the eeprom (true for sense HAT at least), but adding dtoverlay=rpi-sense to /boot/config.txt should do exactly the same as connecting the ID_SC and ID_SD pins (well, presumably the dtb on the boot partition is up-to-date, which might not be true of the one on board the eeprom).

So whatever the eeprom auto-configuration does can be replicated with a single line in /boot/config.txt, in theory... I haven't found the source for the dtb yet so can't be very specific on what the dtb does (besides enabling the i2c1 bus), but I'll post some details if I do find out.

Of course, loading a dtoverlay manually to mimic the eeprom auto-configuration would not necessarily work for other HATs (or add-on with eeprom that don't comply with the mechanical specifications of the format), only those whose dt blob ships with Raspbian.

Anyhow, that's a bit of a tangential on the initial discussion, I just wanted to post where my thoughts had led me while pondering the sense HAT ID_SC and ID_SD pins... I'll see if I can hack something at some point to highlight the eeprom on all the relevant boards, but I'm still of the opinion that they aren't required in the purest sense.

[ghost]

I would like to respond to your message as although pins 27 and 28 should
not be needed for operation of the sense that I have seen and heard
multiple complaints that there sense hat wouldn't work but when they
plugged in pins 27 and 28 it worked again!

On 24 Oct 2016 8:34 pm, "RM" notifications@github.com wrote:

all overlays should have a 'eeprom' tag, so that could be used whichever
way you like. I don't think they should be listed in yhe pin array though.
They are certainly NOT required for operation, neither on the sense HAT,
nor any add-ons with eeprom (which would make them HAT by technical
specifications).

But sure, I have had in mind to make use of the 'eeprom' field visually,
at some point, a light blue tint or something.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#143 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-JVwyKmLSDGchiQUH_Ny-T1PX-ehXgks5q3QhXgaJpZM4KfIgQ
.

[lurch]

I'm curious... what's the use-case scenario where "multiple" (?) people are using the Sense HAT, but connecting it "manually" (?) to the Pi, rather than just sitting it directly on the GPIO header?

[RogueM]

yes, that would be the device tree aspect, discussed herein. What it does, exactly, I'm yet to discover. It could be that those users running into problems have simply not enabled the i2c1 bus. It could be that there is something less obvious that is required before you can get going.

For me though, it's an entirely separate issue, that sits in software land. Obviously, if users feel that auto-configuration is expected when they don't seat the HAT onto the 40w Pi connector I guess it can be hard to match that expectation.

[RogueM]

I guess, another concern would be that you should really NOT connect 2 add-on boards with EEPROM+dtb, including shared pin 27/28... the risk of ending up with a combination not working properly, I would expect, would be much greater than if the same combo left out the ID_SC and ID_SD altogether (at least for one of the board).

... so, I think it's a thin line to walk. I'll try to fix the 'EEPROM' being displayed as part of the details view tonight, but I'm still not sure what is the correct course of action representing those pins on the pinout.

[RogueM]

I've 'fixed' the EEPROM display in the details overview. It will only show up for Sense HAT for now, since, we'll have to decide what constitutes use of the EEPROM in ways relevant to pinout (VIP/PID + basic GPIO map does not IMNSHO opinion).

[ghost]

It allows you to use the GPIO pins to make a sense hat robot and more!

On 25 Oct 2016 7:56 pm, "Andrew Scheller" notifications@github.com wrote:

I'm curious... what's the use-case scenario where "multiple" (?) people
are using the Sense HAT, but connecting it "manually" (?) to the Pi, rather
than just sitting it directly on the GPIO header?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#143 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-JV3f-Y1THSgAgmL4o55sseptKgcVDks5q3lDcgaJpZM4KfIgQ
.