inky: The driver doesn't work anymore

After a few days of usage, the Inky examples don’t work anymore. First I thought, the screen had some defect, but then, just in the case decided to check out how Waveshare reacts to Inky displays. It turns out the hardware still works, but something wrong with the inky.inky_uc8159 driver. It looks like it is blocked or something. Did anyone have experienced it before?

Right now to clean or render any image, I need to do the following:

  1. I render image with the code:
from PIL import Image
from inky.inky_uc8159 import Inky

inky = Inky()
saturation = 0.5
    
image = Image.open(image_path)

inky.set_image(image, saturation)
  1. After the research, I found the specific parts that makes it work.
import spidev
import RPi.GPIO
SPI = spidev.SpiDev()
GPIO = RPi.GPIO

RESET_PIN = 17
BUSY_PIN = 24
DC_PIN = 25
CS0_PIN = 8

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(RESET_PIN, GPIO.OUT)
GPIO.setup(DC_PIN, GPIO.OUT)
GPIO.setup(CS0_PIN, GPIO.OUT)
GPIO.setup(BUSY_PIN, GPIO.IN)

SPI.open(0, 0)
SPI.max_speed_hz = 4000000
SPI.mode = 0b00

RPi.GPIO.output(DC_PIN, 0)
RPi.GPIO.output(CS0_PIN, 0)
SPI.writebytes([0x82])
RPi.GPIO.output(CS0_PIN, 1)
    
RPi.GPIO.output(DC_PIN, 1)
RPi.GPIO.output(CS0_PIN, 0)
SPI.writebytes([0x12])
RPi.GPIO.output(CS0_PIN, 1)

Only after the last block is triggered, it does the magic.

Update:

Similar to that issue: https://forums.pimoroni.com/t/inky-phat-doesnt-update-display/5379/7

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 23 (11 by maintainers)

Commits related to this issue

Most upvoted comments

Excellent! (Albeit sorry for the trouble this is causing you!) I’ve been making do with a jumper wire to short the busy_wait pin!

Mine’s is on its way back to you so hopefully you can tinker with that one 👍

@fotosyn

This is tricky to nail down since I still don’t have a panel I can replicate this with, but try installing the test library:

pip install -i https://test.pypi.org/simple/ inky==1.3.2

And see if that works without the hacks from @rrubyist

The solution provided by @rrubyist worked for me. Thanks for helping me unbrick two units I have here. But I find I need to call this script to actuate any updates that have been sent to the Inky… so while it solves the problem it doesn’t restore out of the box behaviours for me.

Well the EEPROM works at least. I’d fully expect explicitly updating with the SSD1608 type to work, ie from above:

python3 name-badge.py --type phatssd1608 --colour red --name "Hello World"

Guessing not that old, then? You should drop a line to support@pimoroni.com to see if they can sort you out with a replacement.

The UC8159 driver could be getting stuck in a “busy_wait” condition after sending the display data. Your second command - 0x12 - is Display Refresh which is what would normally cause that new data to be displayed.

You’ve pretty much got the latter half of _update() there:

https://github.com/pimoroni/inky/blob/421fe1bbf05c23a5a40b20948e510f804fd5d25e/library/inky/inky_uc8159.py#L301-L322

We seem to be getting intermittent issues with hangs on _busy_wait() and I’ve been unable to replicate them. I wonder if it would be worth limiting the wait period to something shorter and more reasonable, and removing the RuntimeError in a timeout condition.

In retrospect it’s unclear to me why there would need to be a busy wait after writing data anyway. It’s needed after display refresh to avoid triggering a new refresh during an existing cycle, but it seems like DTN1, PON and POF at most need a short, fixed delay.