Tag: RPi

Slowing the SPI clock and updating the drivers having had no noticeable effect on the OLED display corruption, I once again pondered the SH1106 controller timing specs.

The chip reset seems remarkably slow, even at maximum VCC:

I think the relevant code is in the luma.core driver’s serial.py file. On the RPi, it resides in /usr/local/lib/python2.7/dist-packages/luma/core/interface/.

As far as I can tell, the bitbang class handles all the setup and teardown around the actual data transfers, but it’s not clear (to me, anyway) how it interacts with the underlying hardware SPI machinery.

So, let’s add some sleepiness to the Reset code:

        if self._RST is not None:
            self._gpio.output(self._RST, self._gpio.LOW)  # Reset device
            time.sleep(1.0e-3)
            self._gpio.output(self._RST, self._gpio.HIGH)  # Keep RESET pulled high
            time.sleep(1.0e-3)

A few milliseconds, rather than a few (hundred) microseconds, won’t make any perceptible difference.

Similarly, the Chip Select and Address (Command/Data) signals require more delay than might occur between successive Python statements:

This should do the trick, again with excessive delay:

        if self._DC:
            self._gpio.output(self._DC, self._cmd_mode)
            time.sleep(1.0e-3)

... snippage ...

        if self._DC:
            self._gpio.output(self._DC, self._data_mode)
            time.sleep(1.0e-3)

... snippage ...

        if self._CE:
            gpio.output(self._CE, gpio.LOW)  # Active low
            time.sleep(1.0e-3)

... snippage ...

        if self._CE:
            gpio.output(self._CE, gpio.HIGH)
            time.sleep(1.0e-3)

Although it shouldn’t be necessary, I blew away the pyc files to prevent future confusion over who’s doing what with which.

Once again, this will require several weeks to see whether the situation changes for the better.