Stray pixels when using diff_to_previous with ILI9341

Raspberry PI 3, Model B v1.2

Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv71 GNU/Linux

I have a new 320x240 ILI9341 SPI LCD display. If I invoke the welcome.py demo with the options

--interface spi -d ili9341 --width 320 --height 240 --framebuffer full_frame

it operates as one would expect (albeit a bit slowly, varying with --spi-bus-speed).

If I leave off the --framebuffer option (using the default diff_to_previous), then

• the initial attempt at blanking the display leaves white pixels still present and
• any “movement” of drawings can leave a trail of pixels (see attached photo).

In the pi_logo demo, the diff_to_previous option allows dark pixels to momentarily appear around the rotating Pi logo.

Is the full_frame buffer inherently required when using an ili9341-based LCD?

[mattblovell]

@rm-hull :

I was always a bit reluctant to support higher resolution devices because they would always be slow with an interpreted language.

I’m really glad luma added support for the ili9341, though. It’s been quite fun to experiment with. (Photo of the front panel display I’m working on below.)

This makes me wonder what RPi model are you using, and how many amps does your power supply provide?

The board is a Raspberry Pi 3 Model B v1.2. The power supply I have for it claims to provide output of 2.4 A at 5.25 V.

I don’t typically have much plugged into the RPi, but I can try unplugging the USB flash drive and USB mouse and see if that helps at all. The hangs that I reported are just of welcome.py; X and everything else stay up.

I also have an Odroid C4 that is my intended “target” for this project, if I can figure out what’s necessary to get luma.core and luma.lcd up and running on an Odroid board.

One other thing to try would be to add --gpio-reset-hold-time and --gpio-reset-release-time flags

I’ll give those a try later today.

Thanks for making luma such a flexible and (extremely) well-documented package! Matt

---

work-in-progress kodi_panel, on ili9341 using luma:

[mattblovell]

Any suggestions for a better tagline? 😃

No, for that part does seem accurate!

Being relatively new to trying out this whole GPIO aspect of the SBCs, I found the plethora of alternatives just for the RPi a cause of confusion. The following seem roughly equivalent:

• RPi.GPIO
• WiringPi (deprecated in late 2019 by a frustrated author)
• WiringPi2
• gpiozero

Separate from the above are efforts like Adafruit_Blinka (and, from what I can understand, several Python variants).

Once I understood what luma.core wanted to load, I could then search around for an Odroid equivalent.

My (naive) hope is that for such underlying infrastructure we could have settled on a particular Python package and then had clear per-platform versions of that for the various SBCs that are available. Perhaps there’s still too many differences across them to have such a unified approach. It could be that things are simpler than I perceive and I just have yet to find the simplifying key!

Perhaps some hints or pointers on handling non-RPi platforms in the (otherwise excellent) documentation could help?