SoC family dependent dependency

LuRu · July 3, 2022 at 7:04 AM

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?

**jernej** · July 3, 2022 at 12:31 PM

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.

**Da Flex** · July 3, 2022 at 2:07 PM

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

#!/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)

Display More

LuRu · July 3, 2022 at 4:15 PM

Quote from jernej

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.

Quote from Da Flex

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.

**Da Flex** · July 3, 2022 at 5:05 PM

Quote from LuRu

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.

**CvH** · July 3, 2022 at 6:39 PM

we have also libgpiod, that works platform independent

**Da Flex** · July 3, 2022 at 6:59 PM

LuRu Are you sure you need RPi.GPIO? SPI gets activated by config.txt, and that should be all.

CvH I'll try that.

LuRu · July 3, 2022 at 7:11 PM

Quote from CvH

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.

Quote from Da Flex

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)

**Da Flex** · July 3, 2022 at 7:28 PM

LuRu Makes sense. If you need a beta tester for RPi 3B+ with SSD1306, let me know.

ghtester · July 6, 2022 at 12:38 AM

Quote from Da Flex

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.

LuRu · August 3, 2022 at 8:17 AM

Quote from Da Flex

If you need a beta tester for RPi 3B+ with SSD1306, let me know.

I just released a fixed and improved version. The download links are in this post.

Instructions on how to proceed when choosing a font are here.

I'd love for someone else to try it out...