st7735: persist=True not honored

[Rippert]

Type of Raspberry Pi

RPi 3 B+ running Arch Linux Arm

Linux Kernel version

Linux alarmpi 4.19.25-2-ARCH #1 SMP PREEMPT Tue Feb 26 01:20:52 UTC 2019 armv7l GNU/Linux

Expected behavior

I have written a test program to learn how to use your libraries, test.py:

import time
import RPi.GPIO as GPIO
from luma.core.interface.serial import spi
from luma.core.render import canvas
from luma.lcd.device import st7735
from luma.lcd.aux import backlight
from PIL import ImageFont

serial = spi(port=0, device=0, gpio_DC=25, gpio_RST=27)
device = st7735(serial, width=128, height=128, h_offset=1, v_offset=2, bgr=True, persist=True)

gpio_LIGHT = 24
light = backlight(gpio=GPIO, gpio_LIGHT=gpio_LIGHT, active_low=False)

font = ImageFont.truetype("Roboto-Bold.ttf", 14)

light.enable(True)

# Box and text rendered in portrait mode
with canvas(device) as draw:
    draw.rectangle(device.bounding_box, outline="white", fill="black")
    draw.text((10, 50), "Hello World", fill="yellow", font=font)
    draw.text((10, 30), "Hello World", fill="white", font=font)

input()

light.enable(False)
time.sleep(2)

I expected that the graphics will remain on screen and backlight will turn off and stay off after python script concludes.

Actual behavior

I used persist=True in the device setup expecting that the image would stay on the screen, but it did not, the screen becomes blank white. I also tried adding a switch at the end to turn the backlight off expecting it to stay off, but again, backlight is ON and screen is white. Finally, I added a 2 second delay at the very end to be able to see if the backlight control was working. It was, but the screen turns white with the backlight ON after the script ends.

I think that the cleanup of the gpio pins, turning them to tri-state inputs, causes the active high backlight to activate due to a 3.3V pullup in the circuit on the HAT, and the RESET to appear to go low, which would reset the chip.

Am I using the persist option correctly? Anything else I should try?

Thanks -Ted

[Rippert]

I really wanted to leave the backlight off on my display when not using it, and possibly someone else reading this does also, so here's a workaround using the wiringpi command gpio. Since the gpio cleanup in the luma.lcd devices only cleans up those pins that were accessed, using a system call with gpio doesn't get registered with the luma routines and stays how it is setup after the script ends. The new version of test.py sets up the backlight pin (24 in this case) as an output and turns it on before printing its graphics, and then turns the backlight off (leaving the gpio pin as an output) after the script ends.

test.py

import subprocess
import time
import RPi.GPIO as GPIO
from luma.core.interface.serial import spi
from luma.core.render import canvas
from luma.lcd.device import st7735
from luma.lcd.aux import backlight
from PIL import ImageFont

serial = spi(port=0, device=0, gpio_DC=25, gpio_RST=27)
device = st7735(serial, width=128, height=128, h_offset=1, v_offset=2, bgr=True, persist=True)

gpio_LIGHT = '24'
# light = backlight(gpio=GPIO, gpio_LIGHT=gpio_LIGHT, active_low=False)

font = ImageFont.truetype("Roboto-Bold.ttf", 14)

# light.enable(True)
subprocess.run(["gpio", "-g", "mode", gpio_LIGHT, "output"])
subprocess.run(["gpio", "-g", "write", gpio_LIGHT, "1"])

# Box and text rendered in portrait mode
with canvas(device) as draw:
    draw.rectangle(device.bounding_box, outline="white", fill="black")
    draw.text((10, 50), "Hello World", fill="yellow", font=font)
    draw.text((10, 30), "Hello World", fill="white", font=font)

input()

# light.enable(False)
# time.sleep(2)
subprocess.run(["gpio", "-g", "write", "24", "0"])

This doesn't work around the graphics being erased.

[rm-hull]

@Rippert - what is the output of: pip list | grep luma ?

One thing that has never been clear to me is why there is a desire to not get the controlling program to manage its clean-up on exit. By not cleaning-up properly, this leaves the display in an inconsistent state for the next invocation of any program that may want to use the device; admittedly, the luma libraries will always try and reset the device and re-supply the correct init sequence, so this is somewhat a moot point.

Based on the number of issues this has generated in the past, there is obviously a sentiment for this type of behaviour though. Clearly one way of achieving this (whilst keeping the clean-up on exit), is to keep the python program running with a long sleep in a loop. I suppose then there is an overhead in managing the program to run in the background.

Would be interested to canvas people's opinions in why the persist=True behaviour is desirable, and why the alternative is not.

[Rippert]

$ pip list | grep luma
luma.core       1.8.3   
luma.emulator   1.1.0   
luma.examples   0.0.0   /home/alarm/src/luma.examples
luma.lcd        1.1.0   
luma.led-matrix 1.1.1   
luma.oled       3.1.0

In terms of why I want to use the persist=True option: For this specific case, after the cleanup the screen is left with the backlight on and blank. That's a useless and wasteful state. I either want the screen to be off, including the backlight, or to be on with something useful displayed on it. That is really the screen manufacturers fault, since the default really shouldn't be that the backlight is on, but I can see why they want their customers to see something happen when you boot up, so they don't just return perfectly good screens.

I know I could just leave the python script running, but I looked it up and there is a persist option, so I thought it should work.

There's nothing wrong with having your scripts automatically clean up, especially since you provide the persist option. But there are cases where users do want persist=True so I think it's important that it work. Now maybe my system is setup incorrectly, so I'm not trying to criticize, just to get it working.

In more general terms, I can think of using the screen as a sort of "whiteboard" where I print out some useful message about it's state every so often, and instead of having to write some interface code in a python script that I keep running, I might like to just have some pre-written scripts that say one thing or another and call them as I need to.

So I think your persist=False default is correct, but it's useful to be able to override that.

[thijstriemstra]

@Rippert what about pip list --outdated?

[Rippert]

$ pip list --outdated
Package   Version Latest Type 
--------- ------- ------ -----
luma.lcd  1.1.0   1.1.1  wheel
luma.oled 3.1.0   3.1.1  wheel
pip       18.1    19.0.3 whee

[Rippert]

I went ahead and updated everything in the list. It didn't make a difference, which I thought would be the case looking at the commits between 1.1.0 and 1.1.1.

Thanks for pointing out the pip command. I'm just getting started in python, so it's good to know.