Working SPI Display

I have to start from a clean slate, and created a simple script that will atleast automate the setup.
Refer to this new repo:

This is not perfect build simplifies the process. This worked on kernel version: 5.10.69-13-amlogic-g104342c59952

I got it to work with ST7789 lcd, my ST7735 seems broken since i could not run it again after I was able to rebuild the driver for it which is weird.

The new script runs on my Radxa, and everything appears to work - except there’s no display.

This leads me to believe that I have the wiring wrong. Is there a diagram someplace that shows how you hooked yours up? I’ve checked mine a bunch of times and can’t find the issue.

Ahh forgot to mention pin config, here is the setup:
VCC - PIN 4 5v or PIN 1 3.3v
GND - PIN 6
DC/AO - PIN 12
MOSI/SDA - PIN 19
SCLK - PIN 23
SS0/CS - PIN 24
RESET - PIN 35
LED - PIN 17

Hmm - my Waveshare is labeled
VCC
GND
DIN, or “data in”, translates to Master In / Slave Out (MOSI), or Pin 19 on the Radxa
CLK
CS
RST
BL

I had to look up what the translations on these are supposed to be. The only one I couldn’t figure out was DIN, which turns out to have been the MISO/SDA pin.

And yeah, I had mine connected wildly wrong.

UPDATE: I apparently STILL have it wrong, because everything works but there’s no display. This time dmesg contains no errors and it looks like the st7789v device is properly registered and functioning, and the drivers and descriptors installed without a hitch and produce no runtime errors.

At this point I’m off the highway and I’ve run out of dirt road. There are no trails left to follow as far as I can see from here. Anybody got an idea where I should be looking for my next clue?

I get the sense that I’m still missing a step here.

Is your backlight on?

Can you share your lcd screen make/model?

Yes, my backlight is on. An excellent question; the device is, in fact, getting proper power.

Yes - the device is a Waveshare 2" SPI LCD display.

https://www.waveshare.com/2inch-lcd-module.htm

I’ve gone over the wiring and conformed it to what you specified. The backlight works, so it’s certainly getting power, and dmesg isn’t reporting any issues like it did last time (with what was apparently a defective Radxa Zero), so I’m stumped.

In waveshare’s documentation page, it says:
RESX: the reset pin, it should be low when powering the module and be higher at other times;
D/CX: data/command control pin, when DC = 0, write command, when DC = 1, write data

Can you play around with the values setting them 1 or 0 in the dts file,
reset-gpios = <0x30 8 1>;
dc-gpios = <0x30 74 0>;

Also make sure you have the correct phandle values of the kernel you are running it from.

Edit:
I can’t really troubleshoot you situation as I dont have exact same lcd screen. (also cost 20$CAD so wont be getting that one). Another way to troubleshoot is really tap on the SPI connection and see if you have some signals coming out, not trying to go deeper and parse out the signal, but may trying to inspect if you have indeed a working framebuffer not a broken display. Otherwise it can be that the display is broken. I used this Signal Analyzer, works great for debugging signals.

Oh, excellent , a way forward! I’ll give this a try!

Considering you haven’t got my hardware, regarding debugging the situation, I think you’re doing an excellent job, and I’m grateful for your help.

Also, if you want I’d gladly buy you this display if you want one.

I’m also strugging to get an LCD display to work. I did a previous topic on loading DT overlays. Now the device-tree processing part is clear, but I still don’t get a /dev/spidev0,0 device file on the system - a plain ArchlinuxArm with a vanilla linux-aarch64 kernel.

I will follow your advice to try and talk to it on the lines.

Other thing I tried recently : boot latest Ubuntu server edition. There I get the spidev1,0 device, but when using it with gpiod as root it fails (see log below). I specially ported a script to gpiod to make sure it works on a Raspberry Pi 4B. I’m using it with a Waveshare 1in44 LCD pHat, so the pins are static.

Traceback (most recent call last):
  File "qr.py", line 10, in <module>
    from gpiod_lcd import LCD_1in44
  File "/home/lafleur/source/radioboite/gpiod_lcd/__init__.py", line 3, in <module>
    from gpiod_lcd.LCD import LCD, LCD_1in44, LCD_1in8
  File "/home/lafleur/source/radioboite/gpiod_lcd/LCD.py", line 36, in <module>
    _raw_screen = LCD_GPIO()
  File "/home/lafleur/source/radioboite/gpiod_lcd/LCD_GPIO.py", line 52, in __init__
    self.bl_pin = LCD_GPIO._request_pin_out(LCD_BL_PIN, "BL")
  File "/home/lafleur/source/radioboite/gpiod_lcd/LCD_GPIO.py", line 75, in _request_pin_out
    line.request(config)
  File "/usr/local/lib/python3.8/dist-packages/gpiod/libgpiodcxx/__init__.py", line 572, in request
    rv = libgpiod.gpiod_line_request(_m_line, conf, default_val)
  File "/usr/local/lib/python3.8/dist-packages/gpiod/libgpiod/__init__.py", line 499, in gpiod_line_request
    return gpiod_line_request_bulk(bulk, config, [default_val])
  File "/usr/local/lib/python3.8/dist-packages/gpiod/libgpiod/__init__.py", line 542, in gpiod_line_request_bulk
    return _line_request_values(bulk, config, default_vals)
  File "/usr/local/lib/python3.8/dist-packages/gpiod/libgpiod/__init__.py", line 403, in _line_request_values
    status = ioctl(fd, GPIO_GET_LINEHANDLE_IOCTL, req)
OSError: [Errno 16] Device or resource busy

I think if you have to work on SPI natively without needing to compile your own device tree overlays or kernel driver, you might need to look at libmraa to interface with spidev. With that you can probably define pin assignments and be able to use python wrappers and use it for your stuff.

I have strong reserves against libmraa because I had erroneous display with the same Waveshare LCD on a RPi4, whereas both RPi.GPIO and libgpiod succeeded (same hardware, same pin assignment). Would you say libmraa has capabilities the two others don’t ?

@mrkprdo In the end I followed your advice and succeeded in piloting my display using libmraa. I’m running Arch Linux and found a working mraa PKGBUILD for Radxa boards on the AUR. I’ll still try to port my script to libgpiod because it feels better integrated in Arch systems ; that will be another story.

As you mentioned, there is no need to compile a specific DT overlay to get SPI display support. I can witness SPI_A works fine using the default overlay. It’s just that the display’s connection instructions I had (written for a RaspberryPi) need to be adapted - specifically, the instructions I had said to use physical pin 22, but this pin is an open drain on the Radxa Zero, which makes it unsuited for input/output as is (followers, see Radxa Zero GPIO specifics).

In the end, what’s unclear to me is when are your LCD driver or SPI display instructions needed - or what benefit they would bring over using the default overlay together with hardware-specific libraries. As @SCIFI.radio mentioned, there would be a need for newcomers’ documentation on this subject. I hope that my questions will help us understanding what happens in a newcomer’s head :slight_smile:

Anyway thank you very much for pointing me in the right direction !

1 Like

That’s good to hear you have made it to work.
The SPI display instructions i made is to compile dto with fbtft kernel driver and use the display as framebuffer. End goal is to make these displays as monitor like this.. But unfortunately radxa zero spi is quite slow.

I just debug the st7789vw lcd on my radxa zero,It’s running ok,but there is some issues should be avoided:

  1. the reset pin on ZERO should be careful of these open drain pins
  2. It seems difficult to compute or look for the phandler value of the first gpio group,if
    U want use these pins as dc or res pins for tft lcds.
    3.the ko file should be compiled on you host machine,or the magic problem of linux driver would bother you all times

Hi,

I have a Rock 3c and would like to connect a 2,2" QVGA TFT LCD Display, ILI9341 Driver with SPI.(https://www.elektor.de/2-2-spi-tft-display-module-ili9341-240x320 )

Your guide looks very promising. Did you test it on other Rock’s. What ist the correct configuration of the dto file for ILI9341

Thx

Hey, I think I have had the same setup using the adafruit pi tft spi 240x240 1.3" st7789 display. Mine says that it should be able to work, are you using the same exact display? I am using Ubuntu 20.04. THIS IS THE INSTRUCTION SET TO GET THE RASPI TO WORK WITH THE DISPLAY:

cd ~
sudo pip3 install --upgrade adafruit-python-shell click
sudo apt-get install -y git
git clone https://github.com/adafruit/Raspberry-Pi-Installer-Scripts.git
cd Raspberry-Pi-Installer-Scripts
sudo python3 adafruit-pitft.py --display=st7789_240x240 --rotation=0 --install-type=console

Your work is VERY appreciated along with everyone else working on this as it really helps open up portable use implementations of these SBC’s. Please help me with either a simple “yep” or NOPE to get started if you read this.

this version of lcd st7789 is compatible with this image radxa-zero3_debian_bullseye_xfce_b6.img?

hi @houssemmiled, I was able to make the st7735r lcd work on the radxa zero 3w simply by adding an overlay for it (adapted from rk3568-spi3-m0-cs0-waveshare35.dts) (fbft and drivers for st7735r and st7789v are already in the kernel).

The overlay I used is radxa-zero3-spi3-lcd.zip (797 Bytes)