rm-hull / luma.oled

Python module to drive a SSD1306 / SSD1309 / SSD1322 / SSD1325 / SSD1327 / SSD1331 / SSD1351 / SH1106 OLED
https://luma-oled.readthedocs.io
MIT License
805 stars 161 forks source link

Display issues with SSD1351 128x128 OLED display on Raspberry Pi 3 #194

Closed craver2000 closed 6 years ago

craver2000 commented 6 years ago

Hi, I am having some problems with using the library with my 128x128 SSD1351 display(16-bit Color 1.5" -https://www.adafruit.com/product/1431) on my Rapsberry Pi 3.

For instance, I get distorted or clipped display with demo.py initially. I then tried to change the SPI bus speed settings from 500000 through to 16000000 which seemed to help with demo.py at speed 16000000 by enabling a full frame display but it did not significantly improve the display when I ran other example scripts. Examples scripts like runner.py fail to work after a spilt second of flicker on the display, and likewise for animated_gif.py. For 3d_box.py, I get speckled pixels instead of a clean display during the animation. Any ideas how I can resolve this? I have attached some screenshots of the display when these scripts are launched. I tested these by running the following command on terminal (and changing SPI speeds and script name each time): pi@raspberrypi:~/luma.examples $ python examples/demo.py --display ssd1351 --width 128 --height 128 --interface spi --spi-bus-speed 8000000 In terms of hardware connections, I used the SPI connections as described in http://luma-oled.readthedocs.io/en/latest/hardware.html. image

Display screenshots: Clipped display of demo.py at default SPI speed setting photo 21-1-18 3 22 18 am

Clipped and distorted display of demo.py when running at lower SPI setting photo 21-1-18 3 21 11 am

Distorted crawl.py display photo 21-1-18 3 24 05 am

Artifacts on 3d_box animation photo 21-1-18 3 22 49 am

Artifacts on 3d_box animation photo 21-1-18 3 23 09 am

Blue fuzzy artifactual display when running bounce.py photo 21-1-18 3 43 30 am

Four bright blue pixel dots when colors.py is launched. photo 21-1-18 3 52 51 am

Distorted clock.py display photo 21-1-18 4 05 01 am

Terminal states the following when I run my scripts:

pi@raspberrypi:~/luma.examples $ python examples/colors.py --display ssd1351 --width 128 --height 128 --interface spi --spi-bus-speed 8000000
Version: luma.oled 2.3.1 (luma.core 1.3.0)
Display: ssd1351
Interface: spi
Dimensions: 128 x 128
------------------------------------------------------------
/usr/local/lib/python2.7/dist-packages/luma/core/interface/serial.py:164: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  self._gpio.setup(pin, self._gpio.OUT)

But I have also checked and ensured that none of my phat boards or scripts are using the pins that Luma OLED library depends on. Please could anyone advise on this matter, thanks!

rm-hull commented 6 years ago

Looking at the pictures, it almost certainly looks like something else is emitting data on the same SPI channel.

The fact that you see the warning

/usr/local/lib/python2.7/dist-packages/luma/core/interface/serial.py:164: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  self._gpio.setup(pin, self._gpio.OUT)

indicates that there is another program sharing at least one GPIO pin.

Things I would look at to try and isolate the problem:

craver2000 commented 6 years ago

Thanks for the suggestions. I change the CS to CE1 first but that first did not help. Then, I loaded an early raspbian backup image into the SD card and reinstalled the library, and the demo scripts ran properly this time! While I still have that same runtime warning of potential pin clash, I no longer have the flickering, clipping or artifactual display any more. I tested a couple of scripts and they are running very well. Upon investigating further, I realized that the conflict is caused by an installation of a library for a phat board quite a long time ago, which is no longer used now. Would it be possible for me to resolder the DC connection of the OLED to another pin, say BCM 0 (instead of BCM24), and then I run the demo with --gpio-data-command 0 to avoid the pin conflict?

craver2000 commented 6 years ago

Ok, just tried using BCM20 for DC and it works!

rm-hull commented 6 years ago

Glad you got it sorted 👍