Jump to content

OrangePi Zero LTS ili9341 TFT LCD (and later OrangePi Zero 3)


Go to solution Solved by robertoj,

Recommended Posts

Posted

I am experimenting with a cheap ILI9341 screen and mi OrangePi Zero LTS

https://www.aliexpress.us/item/2251832431328471.html

 

I found these recent instructions to be able to display graphics here:

https://ryjelsum.me/homelab/xpt2046-ili9341-opi-zero/

with a reference to a previous experience (without mentioning success)

https://hackaday.io/project/190371-g-edm/log/217902-first-success-with-armbian-nanopi-and-ili9341-touch

and independently, I found these instructions and experiences here:

https://docs.armbian.com/User-Guide_Allwinner_overlays/

https://forum.armbian.com/topic/27457-connecting-banana-pi-m2-zero-with-ili9341-display-over-spi-on-latest-armbian-image/ <-just found it and it has some success with BananaPi M2 Zero

https://tech-de.netlify.app/articles/de547180/index.html

https://4pda.to/forum/index.php?showtopic=782242&st=5060#entry112401076

 

I connected with wires as shown in instructions: https://forum.armbian.com/topic/28674-text-version-of-orange-pi-zero-pinout/

And the LCD's LED input pin to 3.3V

 

I activated the spi-add-cs1 overlay in arbian-config

 

I copied the dts for opiZ into ~/ili9341/ili9341-touch-double-spi-cs.dts

Then, I executed:
 

cd ili9341
armbian-add-overlay ili9341-touch-double-spi-cs.dts

 

Then, I rebooted, and my LCD just looks gray.

 

My armbianEnv looks like this:

verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=spi-add-cs1 tve usbhost2 usbhost3
rootdev=UUID=7d9a7016-73db-4f9c-a5bd-e3e5ab53ffc4
rootfstype=ext4
user_overlays=ili9341-touch-double-spi-cs
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

my armbianmonitor -u: https://paste.armbian.com/arogurekiv

 

I am still not done checking against the experiences with Bpi M2-0, but I ask here: anyone has experience with ILI9341+XPT2046, in either OrangePi Zero or Zero 3?

 

Should I downgrade to Linux 6.1.53?

Posted

Just to keep track of my progress:

 

OrangePi Zero can drive a ILI9341, with this ili9341-spi1.dts, with the fb_ili9341.ko driver (not the drm driver). Works on Linux 6.1.104 and Linux 6.6.44

 

Pin connections inside the DTS code:

 

  Reveal hidden contents

and this armbianEnv.txt

  Reveal hidden contents

 

Posted

Investigating why fb_ili9341 works but ili9341 does not.

 

With this ili9341-spi1.dts, fb_ili9341 gets loaded and TFT shows images perfectly

 

  Reveal hidden contents

 

here's the armbian-monitor -u result https://paste.armbian.com/vimetexiqe

Other results in this successful DTS:

  Reveal hidden contents

 

When I change the DTS to (notice the differences in compatible and rotate/rotation lines)

  Reveal hidden contents

 

The TFT remains 100% white. Here's the armbianmonitor -u: https://paste.armbian.com/segulokeso

Other tests in this failed attempt:

  Reveal hidden contents

 

In both cases, I used sudo armbian-add-overlay ili9341-spi1.dts, and my armbianEnv remained the same:

  Reveal hidden contents

 

Posted

I tried this DTS, to try to declare, reserve, or pin mux the chip select (I don't know what the added block does)

 

  Reveal hidden contents

 

The TFT screen did not work (100% white), but at least I see more pins used in pinctrl (PA2, PA18)

  Reveal hidden contents

 

Posted

So, I temporarily quit the effort to make ili9341.ko work, and continue with fb_ili9341.ko

 

(Note: try changing the reset HIGH/LOW polarity, as advised in https://forums.raspberrypi.com/viewtopic.php?t=358240&start=25 )

 

To make this work with the orangepi zero 3, the DTS needed would be changed in the pinout, and the compatible line:

 

  Reveal hidden contents

 

Now I need to try this at home

  • Solution
Posted

For anyone interested in connecting the ili9341 to an orange pi zero, and use the adafruit DRM driver: ili9341-spi1-drm.dts

 

  Reveal hidden contents

 

I made these experiments, since the LCD is the only one chip in the SPI bus.

* disconnect the LCD's Chip Select -> LCD remains white

* connect the LCD's Chip Select to GND -> LCD displays the login line and linux crashes soon after <- it might be my orange pi zero, which needs a heatsink

 

Update: this thread also refers to orange pi zero 3... the solution (with touch function) is in this post:

https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#findComment-204672

 

Posted

It turned out that my USB power cable was too long... I replaced it with the previous short one and I am back in business.

 

I am experimenting with NOT USING CS. Good progress:

 

In the DTS, comment out with "/*" the line cs-gpios = <&pio 0 13 0>; /* PA13 chip select */

Also, change this line num-chipselects = <1>; to <0>

 

Previous result of: sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

...

  Reveal hidden contents

 

New result, with NO CS configuration:

...

  Reveal hidden contents

...

^ with my next steps, I hope to verify that PA13 is available for other things

 

It plays an h264 file with no hiccups ;)

mplayer -vo fbdev2:/dev/fb0 mj_remember_time.mp4

Posted

When the chip select is not specified, as above, the gpio pin is available for other uses :)

 

I read somewhere that the ili9341 does not need the MISO wire because no information is read from the LCD ever... is this true?

Some people are getting away with it

https://forums.raspberrypi.com/viewtopic.php?t=370089

 

Also, if a wire is loose momentarily, the LCD locks up or turns "white-washed"... is there a way to reset the LCD and its KO module?

Posted

FOR ORANGE PI ZERO:

 

This is the version of the LCD DTS, to use NO CS and all pins in the lower end of the connector: ili9341-spi1-opiz.dts

  Reveal hidden contents

 

To make the touch screen work, use this DTS: ads7846-opiz-spi-gpio.dts

  Reveal hidden contents

 

Confirmed to work in orange pi zero Linux 6.6.44

 

Wiring schematic later... but they are defined in the code comments

Posted

FOR ORANGE PI ZERO 3:

 

This is the version of the LCD DTS, to use NO CS and all pins in the lower end of the connector: ili9341-spi1-opiz3.dts

 

  Reveal hidden contents

 

^ confirmed working in Orange Pi Zero 3, Linux 6.6.31, with drivers included in Armbian 24.8.0-trunk.21 bookworm

 

v My current ATTEMPT to make the touch screen work: ads7846-opiz3-spi-gpio.dts

  Reveal hidden contents

 

It is not working... the errors may be visible here:

  Reveal hidden contents

 

More tests:

  Reveal hidden contents

 

It looks like PC7 is not available for IRQ GPIO due to SPI2... That was unexpected... I will try other pins

Does the opiz3 even have a SPI2???

image.thumb.png.17ba91b3d72564a426826d6a5339f919.png

Posted
  On 10/12/2024 at 3:31 PM, ag123 said:

What do you use to run the ILI9341 LCD? FBTFT?

https://github.com/notro/fbtft

Expand  

 

I use the Linux official DRM enabled kernel module for ili9341... everybody has this KO... look for it in:

roberto@orangepizero3:~/ads7846$ lsmod|grep ili
ili9341                12288  0
panel_ilitek_ili9341    16384  0
drm_mipi_dbi           24576  2 ili9341,panel_ilitek_ili9341

roberto@orangepizero3:~/ads7846$ ls /lib/modules/6.6.31-current-sunxi64/kernel/drivers/gpu/drm/tiny/
gm12u320.ko  ili9163.ko  ili9341.ko  mi0283qt.ko        repaper.ko    st7586.ko
hx8357d.ko   ili9225.ko  ili9486.ko  panel-mipi-dbi.ko  simpledrm.ko  st7735r.ko

 

 

Posted

Thank you ag123 :)

 

Continuing my effort to make ads7846 work with spi-gpio...

 

When I change the GPIO pin from PC7 to PC11 (three places in my DTS), I get the same error:

  Reveal hidden contents

Is my DTS wrong?

Posted

OK. I solved the issue of

sun50i-h616-pinctrl 300b000.pinctrl: pin PC7 already requested by spi2.0; cannot claim for 300b000.pinctrl:71

 

by deleting the fragment, which pre-defines the IRQ. See the DTS for touch chip:

 

  Reveal hidden contents

 

I see these successful messages :)

  Reveal hidden contents

 

The same solution might work for those who want to use native SPI with chip selects, and get the error message I mentioned above

Posted

I either have something miswired, or the hardware doesn't like the spi-gpio, but I have constant problems switching into X11.

 

I want to try the most commonly method: one SPI bus, 2 chip selects, as shown in this example:

https://github.com/dev-null2019/orangepizero2w35tft/blob/main/joyit35a-overlay.dts

 

But modifying it from opiz2w to opiz3.

 

The DTS by dev-null2019 has this connection wiring list:

cs0=ph5 pin 24 (user defined,lcd)
cs1=ph9 pin 26 (_____,touch)
res=pi6
dc=ph4
irq=ph2
mosi=ph7 (native)
miso=ph8 (native)
clk=ph6 (native)
3v3=native
0v=native

 

It looks weird to me that in line 9 of the DTS, only the CS0 is specified, but not CS1... is that normal?

Is everyone feeeding the LCD with 3.3V or 5V? (I was using 3.3V because that works great in my orange pi zero)

Has anyone had success with the backlight gpio parameter? Is it ok to use 5V instead of 3.3v?

 

This would be the modified wiring list, for opiz3:

cs0=ph5 pin 24 (user defined,lcd, next to 5V)
cs1=ph9 pin 26 (native,touch)
res=pc14
dc=pc7
irq=pc10
mosi=ph7 (native, both touch and lcd)
miso=ph8 (native, touch only)
clk=ph6 (native, both touch and lcd)
led=3v3 (native)
5v=pin 5 (native, use next pin ph5 for cs0)
0v=native
                
11 wires, 2 with Y splitter
                
in physical pin order:
     
3=cs0	4=5v
17=3v3	18=res < 3v3 for LED
19=mosi	20=gnd < mosi with Y
21=miso	22=dc
23=clk	24=cs1 < clk with Y
        26=irq

 

  Reveal hidden contents

 

Posted

Hello there. First time posting on this forum so I apologize in advance if there is any issue with my post.

 

I have been learning and using Armbian for some time on an Orange Pi Zero 2W intended for Klipper with an ili9341 as a screen for KlipperScreen. In order to have the display and touch working with the CS0 and CS1 pins, I used the dts provided below. I am not very knowledgeable about the structure required in dts files, so I tried to keep all the values the same from the examples that I found online on this forum and Github and only modified what I required or what seemed to work for my case.

 

Pins were assigned in the following way:

CS0     = Connected to CS from display

CS1     = Connected to T_CS from touch

IRQ     = PI5

Reset = PI6

DC      = PH4

LED    = PI14 (PWM)

 

These were connected to the same pins in display and touch

MOSI = PH7 | Connected to SDI (MOSI) and T_DIN

MISO = PH8 | Connected to SDO (MISO) and T_DO

SCL    = PH6 | Connected to SCK and T_CLK

 

Backlight is controlled by pin PI14 which is assigned to pwm4 in fragment@0 since pwm4 is assigned to PH1 by default on the Orange Pi Zero 2W and that pin was a bit far from the rest. At first I was using gpio-backlight on PI14 to control the backlight, so I left those values commented in the dts just for future reference. For VCC I used the 3.3V pin from the Orange Pi Zero 2W. In regards to CS, I once tried to define both, CS0 and CS1, in cs-gpios at the same time but the dts never loaded when I did this. However touch appears to work fine on CS1 even when only CS0  is defined in cs-gpios. No additional overlays from armbian-config were required for this.

 

Something I noticed and I am not sure if this has to do with my configuration, the drivers, my wiring, or the screen itself, but when the screen was turned off by dpms on an X11 session, touch would stop working on some occasions and touch activity was no longer displayed with evtest which always forced me to reboot the device in order to make it work again. Reloading the ads7846 driver did not help since I always receive an error saying "ads7846 spi1.0: failed to request pendown GPIO" when trying to load the driver with modprobe after unloading it. Due to that issue, I changed the backlight to a PWM pin and instead of completely turning it off, I now set it at the lowest brightness level. I have not yet encountered the same problem again after making this change, so the source of the issue is still a mystery for me.

 

Anyways, I hope any of this information is helpful for the Orange Pi Zero 3.

 

 

  Reveal hidden contents

 

Posted

Thank you for the suggestion :)

 

With my modified DTS, which takes hints from your DTS and my reference, I get the LCD to display with the DRM driver... but no touch events (with evtest)

 

  Reveal hidden contents

 

I dont have more time to analyze this problem for now... but I havent triple checked my connections.

 

Ivano, check whether PI5 (your desired IRQ) is not already claimed by the kernel, with the last command I show up there (pinmux-pins)

 

Maybe you can try other GPIO.

 

Then, if it doesn't work, try changing the level and edge polarity parameter (I talk about it in this thread or the other recent ili9341 thread).

In your case: use PI5 <8 5 _>,

                interrupts = <2 10 2>; /* PC10 - IRQ */ < try changing 2 (active high) into 8 (active low) I HAVE NEVER CHANGED THIS
                pendown-gpio = <&pio 2 10 1>; /* PC10 */ <try changing 1 (edge rising) into 0 (edge falling)

 

Opiz2w reference:

image.thumb.png.1dafe63d95d977f6c8d544e0cb6a7d20.png

 

More useful discussion here: https://forum.armbian.com/topic/27457-connecting-banana-pi-m2-zero-with-ili9341-display-over-spi-on-latest-armbian-image/page/2/#comments

 

 

Posted

More progress: this single DTS configures 1 SPI bus control the ili9341 and XPT2046 touch chip

 

  Reveal hidden contents

 

I needed to specify explicitly both CS in:

cs-gpios = <&pio 7 9 0>,<&pio 2 15 0>; /*PH9=CS0 for lcd, PC15=CS1 for touch*/

 

That "<0>" that I saw in other examples IS NOT WORKING!

 

Ivano, try modifying this DTS. It doesn't have backlight function, so plug the LED wire to 3.3V to test.

Posted

I am glad you are making further progress and thankful for sharing your findings.

 

I tried your suggestions and it appears that the pin for IRQ (PI5) is listed as unclaimed when the dts is not loaded, so it appears to be available for use. I previously tried using different pins for IRQ thinking that maybe the one that I was using did not properly support interrupts and that it was causing the random missing touch problem, but the result was the same and touch was randomly lost after the backlight was powered off. This could happen after a few minutes, but sometimes it did not happen even after a full day. I noticed that the problem did not happen when the backlight was not powered off, which is why I decided to dim the backlight to its lowest value instead of powering it off.

 

When I was first trying to make touch work, I had 0 (edge falling) on pendown-gpio which resulted in touch not being registered. Most of the dts I found online had this value set to 0 (edge falling), so it took me a while to try changing the value to 1 (edge rising) to make it work. Anyways, I tried your suggestion about using different values in "interrupts" and touch was still being registered with the value 8, so I will make further tests with this configuration to see if it makes a different for my case.

 

I also tried the dts provided in your last reply with the required modifications for my board (I only changed the pins to match the ones for my board) and with the backlight now connected to 3.3V, but the dts was not loaded and I was presented with a white screen. Logs displayed issues claiming PH9 (CS1) and said that it was already requested. Once I removed CS1 from cs-gpios, the dts was loaded and the display and touch were working properly.

 

The interesting thing is that while logs were complaining that PH9 (CS1) was already requested when both CS were defined in cs-gpios, pinmux-pins was still listing PH9 as unclaimed. But after removing PH9 from cs-gpios, pinmux-pins then listed the pin as claimed and everything seemed to work. I am not sure why this is happening but it appears that your board requires you to explicitly define both CS while mine only wants one in the dts. Below I will provide some details from loading the dts with both CS and with only CS0 defined.

 

This is with the dts from your last reply with both CS defined which is not working for me. | cs-gpios = <&pio 7 5 0>,<&pio 7 9 0>; // PH5=CS0, PH9=CS1

  Reveal hidden contents

 

 

And this is the same dts with only CS1 removed. | cs-gpios = <&pio 7 5 0>; // PH5=CS0

  Reveal hidden contents

 

Posted

That’s very interesting… why my opiz3 needs both CS defined and the opiz2w only wants one CS defined.

 

but please make further tests and confirm this works with lightdm :D :D 

 

Sudo apt install lightdm xorg-input-evdev

sudo cp /usr/share/X11/xorg.conf.d/45-evdev.conf /etc/X11/xorg.conf.d/

(https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A)_Manual_Configuration)

sudo systemctl disable lightdm

sudo startx

(in second ssh) sudo DISPLAY=:0.0 xinput-calibrator

do the calibration 

plug usb keyboard and mouse

Sudo systemctl start lightdm

check that the cursor moves with touch or pen

right click and 

Posted

Hello again.

 

I followed the steps and performed the calibration and LightDM seems to work fine with the display and touch. I only did a short test, but the cursor was moving together with the pen while in the login screen. I currently have KDE Plasma installed and this desktop environment appears to be too big for this screen resolution, however the cursor was still moving with the pen while being in the desktop and I was also able to drag a window and move it around.

 

The only small issue I noticed is that even after performing the calibration, the cursor was getting a small offset from the touch point the farther I was getting from the center of the screen and this made it difficult to reach the border section and also the corners. I experienced problems closing a maximized window due to this. This was somehow resolved after setting a better value range for the min and max values for x and y in the dts. I got the required values by using evtest, then touching each corner, and comparing the minimum and maximum values registered in ABS_X and ABS_Y. My numbers might require some tuning but they are working fine for now and I am able to reach all four corners without the cursor offset issue. Please note that the values reported in ABS_X and ABS_Y are in a decimal format instead of hexadecimal.

 

  Reveal hidden contents

 

If you experience the same offset problem, please feel free to try this to see if it helps you resolve it. I hope this information is helpful.

Posted

I HAD the same issues with calibration.

The 99-calibration.conf needs to be created, with the output of xinput-calibrator. It is not automatically done.

You also need the evdev.conf file copied from usr/share/... to /etc/X11.

When I wasn't doing this, I did the calibration many times and it wasn't effective.

 

Read https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A)_Manual_Configuration very carefully and follow all steps regarding calibration.

Posted

Thank you for your quick response.

 

I created the 99-calibration.conf file in /etc/X11/xorg.conf.d/ with the values provided by  xinput_calibrator, however it appears that I somehow forgot to copy 10-evdev.conf to /etc/X11/xorg.conf.d/ while testing. After copying 10-evdev.conf to the intended directory and running  xinput_calibrator, I now get a different set of values and after putting them in 99-calibration.conf, the calibration is now being properly applied.

Posted (edited)

Hello Robertoj.

 

Yes, I can control the backlight via /sys/class/backlight/ when it is configured with gpio-backlight or pwm-backlight. You may find below the default dts for the Orange Pi Zero 2W on kernel 6.6.44.

 

  Reveal hidden contents

 

EDIT: In case you were referring to the whole dts from /sys/firmware/devicetree/base, you may find it below.

  Reveal hidden contents

 

Edited by Ivano
Posted

This is the latest dts that I used with pwm-backlight. The only changes I made from the previous dts were moving ili9341 to CS1 and ads7846 to CS0, changing the default calibration values for ads7846, and adjusting the brightness values in pwm-backlight.

  Reveal hidden contents

 

For gpio-backlight I used the following fragment which replaces fragment@0 and fragment@1 from above.

  Reveal hidden contents

 

 

Make also sure that backlight = <&backlight>; is included inside the ili9341 section in order to have the backlight working or it will most likely not power on after the device boots.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines