Random/noisy pixels regardless of what I try to print and the hardware settings

[blacklight]

Today I have received my Mono OLED 128x128 SPI Breakout. After installing on the SPI slot of my Breakout Garden and trying to run some sample code, however, I only get random noise on the screen:

This is some sample code I have tried:

from luma.core.interface.serial import spi
from luma.oled.device import sh1106
from luma.core.render import canvas

serial = spi(port=0, device=0, cs_high=True)
device = sh1106(serial, width=128, height=128, rotate=0)

with canvas(device) as draw:
    draw.text((0, 0), "Hello World", fill="white")
    input()

However, regardless of what I try to print, regardless of SPI settings, width/height and orientation, I always get noise.

I'm running the GitHub installation of luma.oled on a RPi4 with vanilla Raspbian, latest update:

Linux turing 5.4.51-v7l+ #1332 SMP Tue Aug 4 18:40:14 BST 2020 armv7l GNU/Linux

[rm-hull]

Can you run the demo.py in the luma.examples repo and post a photo of the output. That has got a specific set of shapes that will help diagnose the issue.

I notice you are using the sh1106 driver, but the oled device is actually an sh1107. I don’t know if they are compatible?

[blacklight]

I've just tried this command without much luck:

python demo.py --width 128 --height 128 --interface spi --spi-port 0 --spi-device 1 --display sh1106 --spi-cs-high 1

This time I've also tried to remove the other SPI device and move the display to the front. It shows a different pattern of pixels, with more white, but it's still noise. I've also tried to disconnect all the I2C and SPI devices to exclude under-voltage/interference, still with the same results.

When the demo script tweaks brightness and flash I actually see the display dimming/flashing, but the noisy pattern remains the same.

I'm not sure if it's compatible with the sh1106 driver, but that's what the example on Pimoroni reports as the correct driver, and I haven't found any occurrences of sh1107 in the codebase.

[blacklight]

Can anyone advise on what's going on here? Is it something related to a broken/misconfigured driver? Or shall I escalate the issue to Pimoroni because they are advising to use an incompatible driver for their product?

[thijstriemstra]

shall I escalate the issue to Pimoroni because they are advising to use an incompatible driver for their product?

After reading that product page it does seem odd they suggest using the luma.oled sh1106 driver when it's actually a SH1107 display. I never tested a SH1107, certainly not with luma.oled (but apparently they did...)

[rm-hull]

Firstly, I would assume that Pimoroni would not recommend using luma.oled with their breakout board if they hadn't tested it as working. @Gadgetoid could you shed any light on this?

Secondly, @BlackLight from what you are describing it sounds like there is some cross chatter on the SPI lines - please ensure that there no other programs running in the background that talk over SPI and that you have only have the OLED board plugged in.

[blacklight]

@rm-hull that was my thought as well - even though I'd have assumed that the breakout garden supported two SPI devices plugged at the same time. As shown in the second picture, I've also tried to unplug the other SPI board and I've tried plugging the OLED both in the front and back slot, but the results were the same (the only thing that changed was the density of white pixels in the noisy pattern).

[rm-hull]

When running the demo script, try adding the --spi-bus-speed SPI_BUS_SPEED parameter. By default it is 8000000. Try it successively with values of 4000000, 2000000, 1000000, 500000 to see if it a timing issue

[blacklight]

It worked! gpio_DC=9 is the one that did the magic eventually:

from luma.core.interface.serial import spi
from luma.oled.device import sh1106
from luma.core.render import canvas

serial = spi(port=0, device=0, cs_high=True, gpio_DC=9)
device = sh1106(serial, width=128, height=128, rotate=2)

with canvas(device) as draw:
    draw.rectangle(device.bounding_box, outline="white", fill="black")
    draw.text((30, 40), "Hello World", fill="white")

input()

Probably it was related, but I had also run an rpi-update for another issue recently - reverting the RPi firmware back to the latest stable kernel seemed to fix the examples too.

Maybe it'd be a good idea for Pimoroni to mention the gpio_DC=9 option as well for this device - they do indeed mention --gpio-data-command 9 to run the examples, but finding out the Python spi() argument the option is actually linked to took me some digging in the luma.core sources.

And if this configuration is the one that works for sh1107 chipset maybe it could be worth adding an sh1107 object to luma.oled.device with this configuration?

[thijstriemstra]

And if this configuration is the one that works for sh1107 chipset maybe it could be worth adding an sh1107 object to luma.oled.device with this configuration?

Yes, please make a pull request if you can.

Maybe it'd be a good idea for Pimoroni

I would definitely send them some feedback once the sh1107 chipset is supported in luma.oled.

[blacklight]

Yes, please make a pull request if you can.

I have tried to put together a logic for sh1107 that overrides the GPIO data command:

class sh1107(sh1106):
    def __init__(self, serial_interface=None, width=128, height=128, rotate=0, **kwargs):
        super(sh1107, self).__init__(serial_interface=serial_interface,
                                     width=width,
                                     height=height,
                                     rotate=rotate,
                                     **kwargs)

        if serial_interface:
            serial_interface._DC = 9

The problem is that it would override the data command on a serial interface that has already been initialized, so the first attempt to write to the canvas fails with:

RuntimeError: The GPIO channel has not been set up as an OUTPUT

A clean implementation should probably initialize the spi or i2c object inside of the device object, but that wouldn't be consistent with the way the other device classes are implemented.

Maybe it's just worth documenting that sh1107 works with a serial object configured with gpio_DC=9 instead of the default gpio_DC=24?

[rm-hull]

The fact that the DC line is on GPIO 9 is how Pimoroni chose to connect it on their breakout garden board - it is nothing to do with the sh1107 display.

I don't think we need a pull request. I guess we've learnt that sh1107 128x128 OLED can be successfully driven with the sh1106 driver though

[thijstriemstra]

I guess we've learnt that sh1107 128x128 OLED can be successfully driven with the sh1106 driver though

Shouldn't this be documented though?