Touch screen displays for radxa zero

Does Raspberry Pi zero screens work with radxa zero?
I want to make a portable mini PC and I decided I will rather go for the radxa zero then the raspberry pi zero 2w. I want a touch screen about 3.5 inch or under but I heard only the display without touch can work . If the pinouts are somewhat different, would it work If I connect them the right way? If the touch screen does not work it is not a big issue, I already have an Idea what I will do instead. Thank for the help in advance

Depends on the display. I’ve got an HDMI display with power/touch via USB and it works fine out of the box with Linux. SPI displays appear to require some fiddling to get working. CSI displays won’t work at all due to lack of hardware. I2C touch interfaces will probably work with the right device tree configuration but depends on the driver.

I’ve tested HDMI output and it works out of the box. I’ve used I2C successfully as well. I’m currently struggling with SPI to output on a small LCD screen (Waveshare 1"44 pHat) and I can’t make it work ATM. The Radxa team said they would be working on the SPI subject on this forum.

That was for SPI ethernet though, not the screen. We will come back to the screen later. Right now I think cs-gpios is what I was missing in my now-abandoned fbtft installation script. I do not have time to test this right now.

will the radxa zero 2 come with wider range of displays for it? Might wait for it if so

:frowning: I thought SPI was a protocol handled by the kernel, you just loaded the spidev module and voilà, just had to push the data from one end and that was it. Now I come to think that the kernel only provides helpers that have better throughput than raw GPIOs. The program using it still has to push the CLK pin up or down whether sending data addresses or data content.

What if I target low-end screens, like small LCDs or e-papers, can I just bypass the kernel SPI framework and talk to it with eg spi-gpio ? In this case no need for device-tree overlays, just got to pick available pins, right ?

I can see that on a Raspberry Pi 4B with SPI enabled, sudo gpioinfo mentions the CS pins as used. This is not the case on Radxa Zero with the spidev overlay enabled. I added spi1_ss0 to the spicc1 reference in the main device tree, so that it reads

groups = "spi1_mosi\0spi1_miso\0spi1_ss0\0spi1_clk";

and now gpioinfo shows the “spi1 CS0” pin as used (I have the labels because I use a line-names overlay that I recently submitted as a PR, very open to comments). I naively tried adding

cs-gpios = <&gpio 22 0>;  // Physical pin 24, GPIOH_6

to the the second fragment in the spi1-0cs.dts overlay, but I have no working equipment to tell if it’s changing anything.

Hope it helps. As you can see I’m quite desperate to have SPI_B working.

This is how we implemented the initial SPI ethernet ovevrlay. Its bandwidth is only 500Kbps compared to hardware SPI controller’s 6.5Mbps.

This is intentional and you will find another group with spi1_ss0 only. The idea is you have 3 data lines that must be used together, but for chip select you can mix and match with hardware CS pins (can have up to 3 lines) or generic GPIO. So there is no need to bundle them together in the same group, unlike Raspberry Pi that is custom tailored to that board design…