i2c device different to expected

[G1TVL]

Just a note in case someone else trips over the same problem (I searched and didn't find any mention elsewhere)

Using a hyperpixel display, I found the i2c device for the gpio control is at /dev/i2c-22, not /dev/i2c-11 (There is no /dev/i2c-11 device listed)
Easily fixed by changing the relevant lines in LangstoneGUI.c and HW_Test.c, and rebuilding the code. Then all functions are as expected.

I assembled the basic bits of the Langstone a few weeks ago, and forgot about this hickup. Yesterday I did a clean install of V2 on a fresh SD card, and was stumped for a few minutes why the gpio stopped working. Really should make more notes when I'm bodging

Almost all the parts for my Langstone came out of the junkbox, so it's hard to date them, but I think the RPI4 is from early 2020, and the Hyperpixel was purchased more or less when it was launched. The display was tested, but discarded as unsuitable for the project it was intended for. The RPI originally suffered damage to the USB-C port normally only available for power input. This made it unusable for the job at hand, hence it was forgotten in the junkbox.

Dave
G1TVL

[g4eml]

Thanks Dave, the interface used to appear on I2C bus 11, so I am not sure when it changed to 22. Possibly as a result of a raspberry pi update.

I don’t think many people are using the I2C extender chip so it probably hasn’t been noticed before.

I will have a look at the code and see if it can be modified to check all I2C busses.

Colin G4EML

[radiogareth]

I fitted it a long time ago and IIRC set something up from the RPI management screen, probably turning on I2C?? I have diode-ORed it with the PD4 PTT output so either can controll my PTT relay as I use mine for both DATV and NB.
Gareth

[G1TVL]

My guess was that it's because I've got an early Hyperpixel display. If it was changed in an rpi update, I'd think someone else would have seen the problem before now. It seems more likely the early display has some difference either in the hardware, or in what it reports to the kernel at boot.

If no-one else has reported the problem before I would think it's not worth changing the code Colin? Maybe just a note in the wiki in the section covering the MCP23017?

Maybe instead of rebuilding the code, as I did, just adding a symlink to copy the device would be a better approach? It would probably survive an update of the Langstone code that way, I think.

But in any case, just having it noted here on the forum stands a good chance of being found by anyone who trips over the same situation

Dave G1TVL