1.12 SPI OLED . > Micropython?

Support
21

For both lines?

spi1 = SPI(1, baudrate=1_000_000, sck=Pin(14), mosi=Pin(15), miso=Pin(12))

Pin14 is GP10 > SPI1 SCK
GP14 is Pin19 > SPI1 SCK

Pin15 is GP11 > SPI1 TX
GP15 is Pin20 > SPI1 TX (MISO)

Pin12 is GP9 > SPI1 CSn
GP12 is Pin16 > SPI1 RX (MOSI)

display = sh1107.SH1107_SPI(64, 128, spi1, Pin(21), Pin(20), Pin(13))
I don’t know what it’s looking for here, but Pin (13) is Ground?

GP21 is Pin27 > SPI0 CSn
Pin27 is GP21 > SPI0 CSn

GP20 is Pin26 > SPI0 RX
Pin20 is GP15 > SPI1 TX

GP13 is Pin17 > SPI1 CSn
Pin13 Is Ground?

I know DC and CS can be any pin, I’m just trying to get a handle on what pins he used, versus what I want / should use.

22

Ok, I’m back to trying to get it to work on a PICO in SPI mode.
The Breakout garden SPI plug / socket is as follows
VCC
CS > GP 17 Pin 22
SCLK > GP 18 Pin 24
MOSI > GP 19 Pin 25
DC > GP 16 Pin 21
NC
GND
If I use Pin numbers for this line
spi0 = SPI(0, baudrate=1_000_000, sck=Pin(24), mosi=Pin(25), miso=Pin(21))
I get a SCK bad pin number error. Same for mosi and miso
If I do this (use the GP numbers) and no error message follows it
spi0 = SPI(0, baudrate=1_000_000, sck=Pin(18), mosi=Pin(19), miso=Pin(16))

For this line
display = sh1107.SH1107_SPI(64, 128, spi1, Pin(21), Pin(20), Pin(13))
I’m thinking DC ,Reset and CS?
Based on this.

display = sh1107.SH1107_SPI(width, 
                            height, 
                            spi, 
                            dc, 
                            res=None, 
                            cs=None, 
                            rotate=0, 
                            external_vcc=False,
                            delay_ms=100)

display = sh1107.SH1107_SPI(128, 128, spi0, Pin(22), Pin(15), Pin(17))
No errors but just snow on the display? It does appear to go blank for a second just before the snow / static fills the screen.

23

This does not make sense to me. You are calling the Pin-constructor with logical pin-numbers in the first line and with physical pin numbers in the second line. How would the Pin-constructor know that you pass logical numbers in the first line and physical numbers in the second line?

24

Your not the only one confused. Right now I"m entering the GP number for both lines.

spi0 = SPI(0, baudrate=1_000_000, sck=Pin(18), mosi=Pin(19), miso=Pin(16))
display = sh1107.SH1107_SPI(128, 128, spi0, Pin(22), Pin(15), Pin(17))

No errors, but also no text on the screen.

If I use:

spi0 = SPI(0, baudrate=1_000_000, sck=Pin(24), mosi=Pin(25), miso=Pin(21))
display = sh1107.SH1107_SPI(128, 128, spi0, Pin(29), Pin(15), Pin(22))

I get

  File "<stdin>", line 16, in <module>
ValueError: bad SCK pin

So what numbers do I use?
A big thanks for still trying to help. =)

25

You should use logical numbers. In the source code, you can see this: SH1107/sh1107.py at e95a8750ce2445b75ac7ea3c3e2a2135e739f373 · peter-l5/SH1107 · GitHub

It actually starts at line 35. Don’t be confused by the D-numbers, that are Arduino logical names.

26

The original file used as follows.

# spi1 = SPI(1, baudrate=1_000_000, sck=Pin(14), mosi=Pin(15), miso=Pin(12))
# display = sh1107.SH1107_SPI(64, 128, spi1, Pin(21), Pin(20), Pin(13))

Pin14 is GP10 > SPI1 SCK
GP14 is Pin19 > SPI1 SCK

Pin15 is GP11 > SPI1 TX
GP15 is Pin20 > SPI1 TX (MISO)

Pin12 is GP9 > SPI1 CSn
GP12 is Pin16 > SPI1 RX (MOSI) <<<<<< lead me to use GP number not Pin number.
If I enter the Pin number for what the Display Pack SPI socket uses I get the bad pin error?

EDIT:
display = sh1107.SH1107_SPI(128, 128, spi0, Pin(22), Pin(15), Pin(17), delay_ms=200)
Made no difference.

27

This seems correct. And you already tried the rotate parameter.

I just had a glimpse at the CircuitPython driver. It is from Adafruit, and they even link to the shop page of Pimoroni, so the Pimoroni display is supported. Of course you don’t want to use CircuitPython, but you could at least compare the commands that peter-l5 is sending to the display with the commands that CircuitPython is sending to the display:

    _INIT_SEQUENCE = (
        b"\xae\x00"  # display off, sleep mode
        b"\xdc\x01\x00"  # set display start line 0
        b"\x81\x01\x4f"  # contrast setting = 0x4f
        b"\x20\x00"  # vertical (column) addressing mode (POR=0x20)
        b"\xa0\x00"  # segment remap = 1 (POR=0, down rotation)
        b"\xc0\x00"  # common output scan direction = 0 (0 to n-1 (POR=0))
        b"\xa8\x01\x7f"  # multiplex ratio = 128 (POR=0x7F)
        b"\xd3\x01\x60"  # set display offset mode = 0x60
        # b"\xd5\x01\x51"  # divide ratio/oscillator: divide by 2, fOsc (POR)
        b"\xd9\x01\x22"  # pre-charge/dis-charge period mode: 2 DCLKs/2 DCLKs (POR)
        b"\xdb\x01\x35"  # VCOM deselect level = 0.770 (POR)
        # b"\xb0\x00"  # set page address = 0 (POR)
        b"\xa4\x00"  # entire display off, retain RAM, normal status (POR)
        b"\xa6\x00"  # normal (not reversed) display
        b"\xaf\x80\x64"  # DISPLAY_ON + 100ms delay
    )

You should compare this list with the commands from peter-i5 (starting at line 150). Keep in mind that the coding of CP uses “command-length-arg” (e.g. b"\xdb\x01\x35") while MP skips the length part (i.e. _SET_VCOM_DSEL_LEVEL = const(0xDB35)).

Ok, this sounds very tedious, and yes, it is. But there are differences. We don’t really know if the code from peter-I5 ever worked, but I am sure the code from Adafruit works.

And here is the driver: Adafruit_CircuitPython_DisplayIO_SH1107/adafruit_displayio_sh1107.py at main · adafruit/Adafruit_CircuitPython_DisplayIO_SH1107 · GitHub

28

At this point I’m throwing in the towel on trying to get it to work. For now anyway. I’m just going to swap in a color LCD that I know I can use Pico Graphics on. That way I can move on with the coding / tinkering wit my encoder servo setup.

29

Stepping back is always a good strategy. Sometimes problems just need some time to rest. Afterwards you have a good idea or suddenly see a wrong comma in your code you always missed.

I am currently trying to make the Tufty2350 work with CircuitPython and the display just stays black. Using the same strategy here: do something else until a good idea pops up.

30

I’ve had my fair share of unnoticed code errors. Clip and past errors etc. Self taught coding wise, python and micro python, so no big surprise there.
It’s still a ton of fun when you get it right though. =)

32

That display doesn’t have a reset pin.
CS, SCK, MOSI, DC, NC
The breakout garden pins are,
CS, SCLK, MOSI, MISO, GPIO

33

OK, after starting over and doing some sleuthing, I have text being displayed.

BG
Socket           OLED
V+     GP  Pin    V+
CS     17   22    CS
SCLK   18   24    SCK
MOSI   19   25    MOSI
MISO   16   21    DC
GPIO   22   29    NC
Ground            GND

It is the GP number, not the Pin number.

# sh1107 driver demo code v319
# this code is intended for a 128*128 pixel display

print('starting test')

# from machine import Pin, I2C
from machine import Pin, SPI
import sh1107
#print('dir sh1107: ', dir(sh1107))
import gc
import sys
import time #as time
import framebuf
import array


# basic test code SPI
spi0 = SPI(0, baudrate=1_000_000, sck=Pin(18), mosi=Pin(19), miso=Pin(16))
#display = sh1107.SH1107_SPI(64, 128, spi1, Pin(21), Pin(20), Pin(13))
display = sh1107.SH1107_SPI(128, 128, spi0, Pin(16), None, Pin(17), rotate=90)
display.fill(0)
display.text('SH1107', 0, 0, 1)
display.text('Driver', 0, 8, 1)
display.show()
# 
time.sleep(2)

The 0, 0, 1 in display.text('SH1107', 0, 0, 1) translates to X, Y, C. C is color.
Now I just have to figure out if and how to make the text bigger? Right now it’s pretty small. Lean forward and squint small.

EDIT It looks like I needed to also copy the frambuf2.py file to the Pico. I have the long version of the demo file running now. I just have to figure out how to adjust the size of the large text. My neck and shoulders (chronic pain) are killing me at the moment and I’ll have to stop, and take a break. I’ve been at this most of the morning. Lunchtime now.

34

Well done, almost home and dry. Give the shoulders a good rest. Just a thought that you may find using the framebuf2.py the text is a bit blocky as it says it uses the built-in font provided in the framebuf module. I’ve not use the framebuf2, so only conjecture, but you may be able to use other fonts you create with the Peter Hinch font_to_py utility.GitHub - peterhinch/micropython-font-to-py: A Python 3 utility to convert fonts to Python source capable of being frozen as bytecode · GitHub

35

The plan is to use it to show the position of two servo’s. Pan and Tilt servo’s for a camera. There is a picture of the setup above, in one of my posts.
Rotary Encoder for Pan control, OLED position indicator, Rotary Encoder for Tilt control. I was going to display the position as a number -90 to +90 degrees, for each servo. Now I think I may just put a gun sight symbol. Circle with a cross in the center. And have that move position on the display to indicate if the camera is pointing left or right, up or down. Have it move in the direction the camera is pointing. No messing with blotchy text. I’ll also draw a square boarder around the outside edge of the LCD for a reference. Easier to see in the dark. Or just put a fixed dot in the center. Something like that lol.