I created the OLEDproc add-on. It can work with both RPi4 and Orange Pi boards. Now I will be adding support for SPI displays, so I will need to add either virtual.rpi-tools (for RPi) or virtual.opi-tools (for Orange Pi boards) to the dependencies. It looks like I'll have to release and maintain two versions of the add-on even though both will be completely identical except for this one dependency. Is there any way to make the dependency so that I can only have one version that works for both SoC families?
SoC family dependent dependency
-
LuRu -
July 3, 2022 at 7:04 AM -
Thread is Unresolved
-
opi-tools is not LE provided addon, right? Anyway, what part of these addons you need? rpi-tools contain RPi.GPIO, gpiozero, colorzero and lan951x-led-ctl package, which are all RPi specific.
-
I have to mention that RPi.GPIO of RPi Tools isn't reliable. The power LED connected to my RPi 3B+ (GPIO 13 / Ground) switches on and off randomly. I was testing electrical contacts - no problem there. It's definitely a software problem. If I can help to track down the issue, please ask.
My script for the LED:
Python
Display More#!/usr/bin/python import sys sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib') import RPi.GPIO as GPIO import os led_gpio_number = 13 GPIO.setmode(GPIO.BCM) GPIO.setup(led_gpio_number, GPIO.OUT) GPIO.output(led_gpio_number, True) -
opi-tools is not LE provided addon, right? Anyway, what part of these addons you need? rpi-tools contain RPi.GPIO, gpiozero, colorzero and lan951x-led-ctl package, which are all RPi specific.
I use the luma.oled library to control the OLED display. Most common displays with an SPI interface (Aliexpress) have a 7-pin connection where (among others) the DC (Data/Command) and RES pins need to be controlled.
In luma.oled, the RPi.OLED library (or compatible for other SoCs) is used for this.
I created the virtual.opi-tools add-on a long time ago - see Two new addons for Orange Pi (Allwinner) boards. This contains (unlike virtual.rpi-tools) only the OPi.GPIO library.
Regarding the OLEDproc add-on and the SPI interface, I am currently at the stage where it already works with one board (OPi PC), but it is still necessary to test it with other boards (including RPi4). I just ran into a dependency problem in the addon.xml file. In my working version I have this:
Code<requires> <import addon="xbmc.python" version="3.0.0"/> <import addon="script.module.luma" /> <import addon="script.module.cbor2" /> <import addon="script.module.smbus2" /> <import addon="script.module.spidev" /> <import addon="virtual.opi-tools" /> </requires>However, for RPi4 type boards, the last line will need to be this: <import addon="virtual.rpi-tools" />.
But this means that I have to have two versions of addon.xml and thus also two versions of the entire add-on. I wanted to know if there was a trick to fix this and avoid having to release and maintain two versions of the plugin.
I have to mention that RPi.GPIO of RPi Tools isn't reliable. The power LED connected to my RPi 3B+ (GPIO 13 / Ground) switches on and off randomly. I was testing electrical contacts - no problem there. It's definitely a software problem. If I can help to track down the issue, please ask.
I don't (yet) have a problem with the RPi.GPIO. So far I'm only working with OPi.GPIO. However, it seems to work reliably. And if I take into account the use (controlling the display), it is not a nuclear power plant and some random error cannot be a problem at all. In any case, thank you for trying to help.
-
I don't (yet) have a problem with the RPi.GPIO. So far I'm only working with OPi.GPIO. However, it seems to work reliably. And if I take into account the use (controlling the display), it is not a nuclear power plant and some random error cannot be a problem at all. In any case, thank you for trying to help.
The LED goes off for a long time. I just wanted to mention that to avoid unnecessary research.
If RPi.GPIO works reliable for you, then I'll check my installation again. The problem exists since LE 10 for me.
-
we have also libgpiod, that works platform independent
-
-
we have also libgpiod, that works platform independent
I know about it. But it can't be used in this case because luma.oled uses RPi.GPIO, not libgpiod.
Are you sure you need RPi.GPIO? SPI gets activated by config.txt, and that should be all.
Yes, I'm sure:
1. using config.txt I just enable the SPI interface (some spidevX.Y device appears)
2) luma.oled uses the spidev library to communicate with it
3) in addition, luma.oled needs RPi.GPIO (or OPi.GPIO) to control the DC and RES pins (actually a "bitbang" system)
-
LuRu Makes sense. If you need a beta tester for RPi 3B+ with SSD1306, let me know.
-
I have to mention that RPi.GPIO of RPi Tools isn't reliable. The power LED connected to my RPi 3B+ (GPIO 13 / Ground) switches on and off randomly.
On RPi 4B it works fine. Please note the GPIO selection should also reflect a possible dual functionality to avoid any conflict.
I am using GPIO4 and GPIO6 to control relays, GPIO27 for power LED and GPIO5 for power button input. Works 100% reliable with Python script on RPi 4B running LE 11 Nightly.
-
