i occasionally see the st7735 display get corrupted, and nothing short of a power cycle fixes it.
i’m using an automation hat mini, and unfortunately i don’t think the reset pin is supported on that board. the corruption appears as staggered images, partial colors, etc.
things i’ve tried:
-sw reset via spi commands
-reinit of the ST7735 module
-unload/reload of the spi_bcm2835 kernel module
-sudo reboot**
**yes, it persists through a reboot. nothing short of a power cycle fixes it.
What code are you running? I don’t own the Automation Mini but I do have several of those displays in use. Some have been running modified Enviro+ code 24/7 for a month or more. No issues I am aware of.
Pragmatically I guess you’d have to write a blank image to it, to clear it. That should I would think, clear out whats stored in its display buffer. I don’t know how you do that though? I tried doing it a while back but couldn’t get the suggested code to work. I just wanted to blank the secreen so it was all black, but leave my code running in the background. I ended up just turning the backlight off at night.
No, blanking the screen doesn’t work. Anything I write to the display gets similarly corrupted.
I suspect some internal setting is getting changed? I don’t know. Maybe I’ll pull out the datasheet and compare it to the _init(self) code in the ST7735 driver and see what’s not being written.
Until then, I just have to be careful about writing to the display and not do it simultaneously. I have a service that starts up on boot that writes continuously to the display, and sometimes I forget it’s running while I’m doing development, and then I start up some other code that tries to write to it at the same time.
And then there’s nothing for it but to power cycle.
You can setup and use a second display. I have two running on a Pi Zero W on SPI0, and three running on SPI1 on another Pi Zero. They will work as long as they each use a different chip select pin. Or put one on SPI0 and the other on SPI1. I’m thinking the one on SPI0 and the other on SPI1 would be the better choice if your controlling from two different sources. My 2 and 3 screen setups are all being written too, from the one running python file. I only ever access / update one at a time.
Yeah, these things are absolutely not designed to be written to simultaneously, and I’d guess all sorts of bad things might happen depending on how the hardware handles simultaneous writes. I’m surprised a SW reset doesn’t fix it though, and makes me wonder if the issue is on the Central side, rather than ther Peripherial. What are you writing to it using, a Pi?
What’s in the display memory stays in the display memory as long as there is power to the display. It will only change if new data is written too it.
I do believe the software reset Bree is talking about, is the restart of your program that is writing to the screen. My screens all retain an image of what was last displayed when I do a Pi OS shutdown. They just freeze. I have to unplug my power supply to make them go blank.
That being said, if I leave mine as they were when I shut down, leave the Pi powered up, and reboot it. They get overwritten with new info when my program starts up again. All the old data is gone. Same thing happens if I do a reboot whith my python code running. They freeze the image, then a new one is shown when my file runs.
What occurs is the color depth lookup tables are getting corrupted. According to the Sitronix datasheet, the LUTs are not defaulted on a SWRESET, only on power up or HWRESET. So app restart or even “sudo reboot” is not enough to correct it.
I was able to account for this by adding code to default the LUTs to the ST7735 module’s _init() function.
ST7735_RGBSET = 0x2D
# update color depth lookup tables for 16-bit 565 color.
# these are only reset to defaults after a
# power on or HW reset (not a SW reset).
self.command(ST7735_RGBSET) # Set color LUT (0x2D)
# red (5-bit, 32 colors)
for color in range(0, 32, 2):
self.data(color)
for color in range(33, 64, 2):
self.data(color)
# green (6-bit, 64 colors)
for color in range(0, 64):
self.data(color)
# blue (5-bit, 32 colors)
for color in range(0, 32, 2):
self.data(color)
for color in range(33, 64, 2):
self.data(color)