So I need to get the i2c working on the RPi zero with the hyperpixel 2.1" round display. Following the instruction here is not much help;
Getting Started with HyperPixel 4.0 (pimoroni.com)
You add a link to make i2c-3 seem to be i2c-1. But really this only helps a program that insists on using i2c-1.
If I issue a i2cdetect -l I get;
i2c-3 i2c i2c@0 I2C adapter
i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – 15 – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
The address 15 is their regardless of whether my 16IS752 is connected or not.
If I look at the outputs of the 16IS752 PCB, the IRQ line is high. Using a scope I can see the SDA line get some data when the i2cdetect -y -3 command is given. So yay…
But the address of the 16IS752 is set to 0x9A.
Looking at this elsewhere it seems I need to add a line to the config.txt something like
dtoverlay=sc16is752-i2c,int_pin=24,addr=0x48
Thing is how do you know the pin numbers of the i2c port that has been broken out on the 2.1" display so I can get the kernal talking to the SC16IS752
I “think” the software i2c uses the touch pins. And 15 is the touch controller? You could check that with an ohm meter.
GPIO 10 Touch Data is maybe SDA.
And GPIO 11 Touch Clock is SCL?
Hyperpixel4 at Raspberry Pi GPIO Pinout
Somebody from Pimoroni can confirm this if you want to send them an e-mail.
Contact Us for Raspberry Pi Technical Support - Pimoroni
There is a link to the pinout on the product page. You can see that the touch-chip uses GPIO10 for SDA and GPIO11 for SCL.
The overlay for the SC16IS752 probably insists on using i2c-1 and I am not sure if this overlay uses the device-files. But you can try the symlink and then test i2cdetect -y 1 to see if this helps. If not, maybe you can recompile the overlay for i2c-3.
If I use a multimeter and check where the 2.1" diplays I2c port goes to on the RPi zero it maps;
SCL Pin 23
SDA Pin 37
IRQ Pin 19
Which is interesting as the Hyperpixel 4 pinout link you gave shows;
PIN 23 GPIO 11 Touch Clock
Pin 37 GPIO 26 LCD program data
Pin 19 GPIO 10 Touch Data
So your comment of Addr 15 being touch screen is probably correct, and the i2c breakout connector is sharing the port with the touch data i2c.
Which leads me to wonder why when issue the i2cdetect -y 3 I don’t get the SC16IS752 address in the results. Not knowing enough about the command I guess I just need to start issuing commands to the 16IS752 and see if it starts to obey.
Thanks for the help its a small step in the right direction figuring this out.
Your SC16IS752 is not on i2c-3. The overlay configures it to be on i2c-1. See linux/arch/arm/boot/dts/overlays/sc16is752-i2c-overlay.dts at rpi-5.10.y · raspberrypi/linux · GitHub (line 8).
I would try to remove the overlay, reboot, attach the device and test i2cdetect -y 3 again. Then try to load the driver module manually (probably something like sudo modprobe sc16is752). I am not sure if the module accepts parameters, so this is also something to google. Ideally, it would accept the i2c bus-number as an argument so you could direct the driver to use i2-3.
Another thing to check would be the source code of the driver module. If this module uses the device-file /dev/i2c-1, then you might get away with symlinking /dev/i2c-1 to /dev/i2c-3 after all.
I do remember a project where I needed an i2c-device on a different bus. I ended up skipping the overlay and using Python to directly configure and access the correct i2c bus. This was possible since I had a working Python driver, but of course this is not a generic solution for all devices.
I haven’t put any dtoverlay for the 16IS752 into the config.txt file…yet.
The hyperpixel doc’s would like a sym link done to put in i2c-3 to i2c-1, so that drivers etc will work, and when you do this i2cdetect -y -1 gives the same results as i2cdetec -y 3…no surprises there. This would then allow the dtoverlay command to install the driver and talk to it without changes to talk to i2c-3. This isn’t something I have done yet however, which I guess is the reason I don’t see the 16IS752 in the i2cdetect -y 3 command.
I am using python to talk to the 16IS752, so I might see if I can talk to it without dtoverlay complications. Still wading through the 16IS752 doc so I’ll get back to the driving it soon.
In this case I would really skip the overlay stuff. You should check your driver if the i2c bus-number is hardcoded (e.g. with something like SMBus(1) or if you can pass it to the constructor or a configure-method or whatever.
Well after much mucking around…I used the arduino sketch to check the SC16iS752 i2c address. It found it on address DEC77. So put the wiring back to the rPI.
I put a scope on the SDA/SCL outputs from the 2.1" display, and noticed that I had and SCL signal, but no SDA. Resoldered the IDC connector on the pins 19,23,37 and then I got the SDA alive.
Now it sees the SC16IS752
pi@raspberrypi:/boot $ i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – 4d – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
So here I was getting caught up in software…should have pulled the scope out earlier. Oh well off to figure out smbus and get it talking out i2c-3…