hyperpixel2r

hyperpixel2r copied to clipboard

Maybe I misunderstood, but I can't get touch to work as a mouse on the desktop. With all the Pimoroni drivers & Python libraries installed I can use touch in my Python programs, but I can't control the desktop. Is it supposed to work?

Also, I am not sure about I2C. There is no i2c-3.

Finally, hyperpixel2r-rotate doesn't work, I had to set rotation in config.txt with

display_lcd_rotate=2

I have two displays behaving the same, one with a Zero W and one on a Zero 2W, and both running freshly installed Buster 21-12-02.

I had a look at this issue but that didn't help me any.

Here is some system info:

pi@raspberrypi:~ $ dmesg | grep i2c
[    8.393724] i2c /dev entries driver
[   15.638781] gpio-10 (i2c@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[   15.638950] gpio-11 (i2c@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[   15.647469] i2c-gpio i2c@0: using lines 10 (SDA) and 11 (SCL)
pi@raspberrypi:~ $ i2cdetect -y 3
Error: Could not open file `/dev/i2c-3' or `/dev/i2c/3': No such file or directory

What am I missing?

I just found this issue which has a solution for making touch work on the desktop by using the uinput-touch.py example (does not take rotation into account).

Still wondering about i2c-3 though... anyone?

You should be using i2c-detect -y 0 if you want the i2c bus on the board. I don't think the i2c bus it uses is entirely predictable, but you can see it's using 0 from this line:

[   15.647469] i2c-gpio i2c@0: using lines 10 (SDA) and 11 (SCL)

@ClemensAtElektor curious; I use a Pi 4B (Raspbian Buster), and I have the same issue that there is no i2c-3 ; watching this issue to see if it gets resolved

Look in the /dev folder for a file starting with 'i2c':

$ dir /dev

In my case it is i2c-11. Redirecting it to i2c-1 makes it work with other libraries that expect i2c-1:

$ sudo ln -s /dev/i2c-11 /dev/i2c-1

No idea though why it is 11 and not 3 or something else for that matter.

In my case, it pops up at i2c-7, but the main issue is both the HyperPixel 2r and the second i2c device connected via the break-out pins show up in the i2c-7, and there doesn't seem to be two i2c devices as advertised. When I now symlink the i2c-7 to i2c-1 and try any code for the second device, the screen just produces garbage, even though the second device itself works. This doesn't make any sense to me. Perhaps I am missing something? I tried two devices now, an RFID reader/writer, and an analog-to-digital converter.

$ i2cdetect -l
i2c-7	i2c       	i2c@0                           	I2C adapter
$ i2cdetect -y 7
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

Here, '15' is the hyperpixel, and '48' is the PCF8591 ADC. If I try to use this "single" i2c interface:

$ sudo ln -s /dev/i2c-7 /dev/i2c-1
$ sudo ./pcf8591 

-> screen garbage

Correct me if I'm wrong, but I2C device 0x15 is the touch sensor and unrelated to the display itself. I have an MPU6050 accelerometer connected to the bus and that works fine in an SSH terminal while running the clock demo at the same time. Maybe your flat cable is the problem, creating cross talk between signals? I have my display plugged on a Zero, so connections are short.

The flat cable was added just yesterday, the problem exists from before, connecting it directly; the display works correctly on its own. If 0x15 is the touch sensor, why would the display produce garbage when talking to i2c via the aliased i2c-7? (if I do not alias, it is not possible to use the RFID or ADC, so they are definitely not talking to the default i2c device which has been disabled by the HyperPixel software installation).

I'm starting to think that they only ever tested this software i2c bus on a Pi zero, but never on a Pi 3B or 4B, and that these computers behave differently, somehow. The PCF8591 should not be much different from an MPU6050 in terms of polling the sample values.

You are on Buster, right? Currently I use the display on a Zero 2W which is basically an RPi3 and I2C works fine.

There should not be two i2c busses- the external i2c pins on the header are connected to the same physical pins as the touch controller. i2c is a multi-drop bus, so you'll see multiple devices on - for example - i2c 11, each with their own discrete i2c address.

Ideally you should not need to symlink, but rather provide the right i2c bus number, or an i2c object pointing at the right bus, to whatever library you use. There will... usually... be a way to accomplish this.

Worth noting that the SPI bus for the display controller uses the same exact pins as the i2c bus. This should not normally cause a problem, since the chip select for the display controller (GPIO 18) will not be asserted. If that pin is somehow left high, then all kinds of weirdness can ensue. The library you're using might be asserting this pin and causing the display weirdness you're seeing.

The default i2c is disabled because those pins (GPIO 2 and GPIO 3) are the absolutely vital DPI V-Sync and H-Sync.