Adafruit PiTFT EEPROM Pins

[Jolyan]

Adafruit support mention including the EEPROM lines on pins 27,28 in this support forum post https://forums.adafruit.com/viewtopic.php?f=19&t=96823&p=485549&hilit=pitft+datasheet#p485549

But the datasheet and your pinout don't show this, just checking this is right and the support post is wrong? https://cdn-learn.adafruit.com/assets/assets/000/026/348/original/adafruit_products_pitftplusch.png?1436454821 https://pinout.xyz/pinout/pitft_plus_35

Thanks Jools

[Jolyan]

Just tested this and for the PiTFT Plus 3.5 both pins 27 and 28 are needed.

[Gadgetoid]

This is presumably for doing auto-detection of the PiTFT and loading a device tree overlay or configuration settings accordingly?

At the moment we don't include the EEPROM pins in Pinout pages since they'd - in theory - be required on every single HAT (it's in the HAT spec that an EEPROM must be included) and would, in most cases, just add visual noise.

This includes Sense HAT, which uses EEPROM detection to load a glut of specific drivers and software in order to get it running.

I dimly remember a conversation about this somewhere, but I can't recall the outcome. It may have been "if users are advanced enough to wire up a HAT manually, they can probably handle the software." We may need to re-evaluate that decision.

[RogueM]

we basically tag this as part of the eeprom setting, which will show on the right hand side. In this case, if the eeprom is required to load driver, which I don't doubt is the case, then it should be changed to setup in place of yes in the overlay.

Ideally, that setup value would also have an effect on the pinout, which is the only case it is reasonable to expect pin27-28 to be marked as 'used'... of course that could be done manually by declaring these pins, but I think it should be automatic, and preferably the highlighting in a different colour than the standard for required pins.

[RogueM]

right, I changed the eeprom setting, but at some point it would be good to define the ID_SC/SD pins handling in the html renderer... marking this one as an enhancement for now.

[RogueM]

just to expand on this though... under Raspbian, it is very likely that manually loading the dtoverlay that ships with the OS would be all that is needed to make connecting pin27-28 unnecessary.

In that sense those lines really have a special meaning: technically you shouldn't connect pin27-28 on more than one HAT featuring autoconfiguration... the net result is that neither will work without manually loading the drivers in another fashion.

Let's take the case of wanting to use the PiTFT alongside the Sense HAT... well, the easiest way would be to connect pin27-28 on the Sense HAT but not the PiTFT, then load the pitft dtoverlay in /boot/config.txt

... is this pretty advanced and potentially confusing for newcomers? yes, but that is also why the HAT specs don't allow/expect multiple HATs being used concurrently. By doing so, the philosophy is that there is no (pin) conflict possible and everything should just work.

Is this successful in this respect? I think I would answer yes to that question, as long as you use HATs in the fashion intended:

• only one HAT at a time
• no additional add-on or access/use of GPIO pins
• HAT properly seated on Pi header (taking/covering all 40 pins)
• be sure the HAT was seated before boot (and preferably when the Pi was shut down)

... restrictive? well, yes, but you can't have your cake and eat it! (despite what politicians in the UK seem to think)

[Jolyan]

Thanks guys, that all seems to make sense although I have to admit some of it is a little being my knowledge but I get the general jist. I've not done much with direct wiring HATs or any devices that normally sit directly on the headers. I was following the datasheet schematic but this does not show the EEPROMs in use either, or I misread that.

I do understand that the pinout diagrams may not be designed to show EEPROM pins but it worth nothing these somewhere on the page for each, just to be a bit more inclusive.

It may help to understand how I came about to be adding the screen and what OS' I am using.

I am building a prototype handheld game console. I have been testing with the screen mounted direct on a Pi2 but am about to transfer work to a PiZero and start building more in end formats. This needs direct wiring and input controls addding.

I have been testing with RetroPie installing the Adafruit pitft installer on top and then manually configuring the screen. This process starts with configuration being completed via HDMI first.

With the screen fully working and all tested I then wired up with jumpers as a test before soldering, following the schematic and the limited references on the Adafruit site but just kept getting a white screen. A search then turned up the pinout and the forum post. I don't know why I didn't check pinout first, it's great, but the forum post made me realise no information was a complete mapping.

Bit of a learning curve. Hope this helps, pinout does!

Cheers Jools

[Jolyan]

I've now tested with the Adafruit PiTFT Raspbian image and RetroPie OS with and without EEPROM pins it only appears to be an issue when you complete the install and initial configuration with the pins connected. Doing so without from the start appears to be the stable option.

So I'd suggest the advice given on the Adafruit site is not correct and is not needed and should not be recommended for this screen.

Hope I haven't wasted your time. Thanks again. Jools

[RogueM]

hum, that does not quite match what a HAT EEPROM provides funtionality wise. The only thing it does is load - until the next reboot - potentially at least (that is up to the board developer) drivers... they will be reloaded in the same fashion on each reboot when the HAT is fitted.

... in other words, it does zero change to your system, in a permanent fashion.

my best guess would be that the setup/configuration script only makes conditional changes, and skips some parts of the config writing if the HAT itself has enabled what those triggers check for. I would have to check the scripts in details to see if that is what is happening.

either way, it does not hurt to mention this board has autoconfiguration - from your report, it clearly does (and I would have expected it, if for no other reason but Raspbian ships with a dtoverlay for it).

[Jolyan]

The Adafruit Image come ready to go but this is the manual install instructions to customise the kernal, I see it includes configuration for the device tree: https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/detailed-install

When using the RetroPie image first (I need to do this to use RetroPie as installing on top of Raspbian leaves the PiTFT unstable, I need to run the fbcp script and manuall config the HDMI output as per these instructions: https://learn.adafruit.com/running-opengl-based-games-and-emulators-on-adafruit-pitft-displays/pitft-setup

Bottom line is it appears setting up the screen works with or without the EEPROM pins but you don't seem to be able to change this post install. Or not to remove them anyway. The other fact was, using the schematic and the Adafruit vague pin references was a pain to say the least, pinout saved the day. Thanks.

NB. I don't know if the 26 pin panel has anything to do with the EEPROM requirement, I haven't used these and wasn't planning to, but the screen provides a 26pin header as extra GPIO but as there's no information on this and again following the schematic was a headache and I couldn't work out which would be ground so decided to ignore it, so it's untested as far as I am concernded. Just a thought.

[RogueM]

I still don't understand why hooking up the eeprom initially then remove makes any difference. As far as I can tell their script makes no assumption about the version of the TFT it is setting up, so will set everything as if no EEPROM was in support for providing configuration.

but anyhow, to answer your question about the 26-way header on the bottom, as far as I can tell it is so you can use the version on an older Pi (and in the original it seems you could choose to orient the screen in portrait or landscape mode)... so these are duplicate lines that you do not need (although if for some reason they are more practical for your wiring they should be exactly as valid).

[RogueM]

err, no, the header is a mirror image, so it wouldn't work for hooking up a Pi... I suspect this may be for the PiGRRL project.

https://learn.adafruit.com/assets/26347

... anyhow see how the 2 headers are connected in this picture, so you can identify the ground points if needed.

[Jolyan]

That's what I was using it for, not specifically the PiGRRL setup but a handheld gaming prototype, so am connecting a number of switches, audio etc. The adafruit docs state the 26 pin is for extra GPIO, I guess I will have to do the line tracing and make a list of the connected GPIO, would it be of use to pinout?

I will also test the EEPROM again, as I remember on reboot once the pins were removed the screen was still trying to present the image but badly ghosted and pixelated. I can record the results if that helps. I will also check to see what logs the RetroPie OS creates and send anything useful.

[RogueM]

I suspect that the image degradation would be related to the clock rate or fps.

but, yes, the 26pin header is just a breakout, since you (would normally) place the TFT on the Pi header, you need a way to access the pins not used by the screen to wire in button inputs etc. Like I said, it's just a mirror image of pins 1-26.