Advice on luma.oled examples

[peterbmckinley]

Hi All,

Bear with me but I'm trying to get my head around the minefield of i2c, v SPI v luma.oled v ssd1306 v sh1106 v PIL v Pillow v Python v Python3 v pip v pip3 (etc. ad nauseum).

Long story short, I have my 1.3" monochrome I2C OLED working fine using the method and examples here:

https://github.com/codelectron/ssd1306.git

All I want to do, mainly as a fun learning exercise, is get some of the luma.oled examples also working.

Rather than boring everyone with ALL the details, my question is are all the examples in luma.oled for an SPI display? (mine is I2C). I tried the first 5 and none of them work, yet for example maze.py from codelectron displays fine (after I edited to text to select SH1106 instead of the default SSD1306, the inevitable issue with larger 1.3" displays).

I'm hoping the answer will help some other newbies in the same frustrating boat.

FYI platform is the latest Armbian. "Welcome to Armbian buster with Linux 5.4.45-sunxi" running on an Orange Pi Zero

[peterbmckinley]

Perhaps I should point out, I followed the instructions to the letter from this page onwards, resolving all dependencies and errors:

https://luma-oled.readthedocs.io/en/latest/hardware.html

then applied the fixes discussed here, with no errors:

https://github.com/rm-hull/luma.led_matrix/issues/151

and finally cloned the luma.oled examples from here:

https://github.com/rm-hull/luma.examples.

As I said, is the issue I'm using an i2c display and the examples are all for SPI? Or what :)

[rm-hull]

From what I can gather https://github.com/codelectron/ssd1306.git is a fork of this project made to work with orange pi, and it hasn’t been updated for many years.

When you run the examples, are you supplying any command line arguments, and what do the examples print out?

I have a feeling that orange pi has its i2c on a different bus to that on the raspberry pi .... so you would be looking for a value of “3c” somewhere in the output when you run the “i2cdetect -y 1” command. If you don’t see anything try 0 or 2 instead of 1. Once you do see “3c”, you will have identified the correct bus, so if you run “python examples/demo.py --help” You’ll see there is an option “--i2c-port” where you can override with the correct bus number.

[peterbmckinley]

Hi Ian,

Given this is for a whole other platform would it be better to fork the project into an Orange Pi version, rather than take up your time in a Raspberry Pi forum. I'm happy to post outputs when I get home, but I thought I should ask the question. I'm not well up on Github "protocol".

The OPi's have been around for a few years now, look like they're here to stay and they have quite a range. Perhaps they deserve their own fork, what do you think?

I wish they hadn't removed support for the TV Out feature after kernel 3.4.113 on the basis it "wasn't very good". It was easily good enough to set up Triggerhappy, and I've yet to find a way that works on a headless SBC since they dropped it.

But that's for another day..... So what do you think, is a fork too radical?

Peter

On Mon, 29 Jun 2020, 20:33 Richard Hull, notifications@github.com wrote:

From what I can gather https://github.com/codelectron/ssd1306.git is a fork of this project made to work with orange pi, and it hasn’t been updated for many years.

When you run the examples, are you supplying any command line arguments, and what do the examples print out?

I have a feeling that orange pi has its i2c on a different bus to that on the raspberry pi .... so you would be looking for a value of “3c” somewhere in the output when you run the “i2cdetect -y 1” command. If you don’t see anything try 0 or 2 instead of 1. Once you do see “3c”, you will have identified the correct bus, so if you run “python examples/demo.py --help” You’ll see there is an option “--i2c-port” where you can override with the correct bus number.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rm-hull/luma.oled/issues/289#issuecomment-651316617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFONLDKTW5CYWBPQZJOMKBDRZDUCBANCNFSM4OLOH2AQ .

[peterbmckinley]

Oops dont ask why I put Ian!!

Is there a particular example you want me to try, which is the simplest? Bear in mind I'm using i2c. I have SSD1306 and SH1106 displays so it doesn't matter which the example is set up for.

Peter

[rm-hull]

It should (and does) work on orange pi ... here is an app I wrote some time back: https://github.com/rm-hull/weatherstation targeting orange pi zero. Other folks have got it working on other sbc’s too.

The default for all the examples is ssd1306 on i2c, so it doesn’t matter which you choose.

The important thing is to determine the correct bus first and foremost

[peterbmckinley]

You were 100% correct about the wrong bus, once I added the argument - - i2c-port 0 it worked. Thank you so much!! Sheesh... you live and learn.

Incidentally, in my case the examples have to be run with python3, if I try to run them with python I get a "No module named luma.core" error. Its just a side by side version thing.

Its not correct to say it doesn't matter which screen, my 1.3" screen uses an SH1106 controller and the image is corrupted. Its fine with the 0.96" display with the SSD1306 controller, natually. In the codelectron/ssd1306.git maze.py example there was an option to select SH1106 (away from the default SSD1306) which made it work. However that option doesn't seem to be there in the demo.py and the maze.py in your examples. (I haven't looked at any of the others).

Is there another switch to avoid the classic 1.3" SH1106 display corruption. I'll try to upload some photos. I realise this is presumably another Orange Pi quirk and that the displays are interchangeable on RPi's.......

On Mon, 29 Jun 2020, 23:20 Richard Hull, notifications@github.com wrote:

It should (and does) work on orange pi ... here is an app I wrote some time back: https://github.com/rm-hull/weatherstation targeting orange pi zero. Other folks have got it working on other sbc’s too.

The default for all the examples is ssd1306 on i2c, so it doesn’t matter which you choose.

The important thing is to determine the correct bus first and foremost

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rm-hull/luma.oled/issues/289#issuecomment-651399706, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFONLDKA5ZSEMB6WDBOGD23RZEHS7ANCNFSM4OLOH2AQ .

[peterbmckinley]

[peterbmckinley]

Just to further clarify, the Orange Pi Zero has two i2c bus connections, TWI0 and TWI1. Needless to say when I switch over to TWI1 the examples run without any arguments.

Happy days :)

[peterbmckinley]

I've edited demo_opts.py in the old codelectron ssd1306 folder to default to Bus 1 as well, so all the examples are now harmonised.

import argparse

parser = argparse.ArgumentParser(description='oled arguments') parser.add_argument( '--port', '-p', type=int, default=1, help='i2c bus number',

The only thing that doesn't work is the 1.3" display with the luma.oled examples.........

Here is demo_opts.py in its entirety, if that helps:

import argparse

parser = argparse.ArgumentParser(description='oled arguments') parser.add_argument( '--port', '-p', type=int, default=1, help='i2c bus number', ) parser.add_argument( '--address', '-a', type=str, default='0x3c', help='i2c display address', ) parser.add_argument( '--display', '-d', type=str, default='sh1106', help='display type, one of ssd1306 or sh1106', )

args = parser.parse_args() if args.display not in ('ssd1306', 'sh1106'): parser.error('unknown display %s' % args.display) try: args.address = int(args.address, 0) except ValueError: parser.error('invalid address %s' % args.address)

import oled.device Device = getattr(oled.device, args.display) device = Device(port=args.port, address=args.address)

[peterbmckinley]

--display sh1106

duh...............

LOVE IT, great experience and great examples. Good work Richard thank you so much