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:
- 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)
- 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
- Soft fail busy wait for #132 Allow busy-wait to wait for a minimm sensible time and timeout without raising a RuntimeError. This should - hopefully - correct issues with some Impressions panels stic... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Soft fail busy wait for #132 Allow busy-wait to wait for a minimum sensible time and timeout without raising a RuntimeError. This should - hopefully - correct issues with some Impressions panels sti... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Soft fail busy wait for #132 Allow busy-wait to wait for a minimum sensible time and timeout without raising a RuntimeError. This should - hopefully - correct issues with some Impressions panels sti... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Soft fail busy wait for #132 Allow busy-wait to wait for a minimum sensible time and timeout without raising a RuntimeError. This should - hopefully - correct issues with some Impressions panels sti... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Soft fail busy wait for #132 Allow busy-wait to wait for a minimum sensible time and timeout without raising a RuntimeError. This should - hopefully - correct issues with some Impressions panels sti... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Soft fail and minimum time for busy wait for #132 Allow busy-wait to wait for a minimum sensible time and timeout without raising a RuntimeError. Additionally force busy-wait to wait for at least th... — committed to pimoroni/inky by Gadgetoid 2 years ago
- Merge pull request #143 from pimoroni/patch-busy-wait Soft fail busy wait for #132 — committed to pimoroni/inky by Gadgetoid 2 years ago
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:
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:
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 theRuntimeError
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
andPOF
at most need a short, fixed delay.