Posts by LuRu

  • OLEDproc Add-on

    Quote from livs
    Code
    Error Contents: BOARD numbering system not applicable on compute module

    Ah, so that's a surprise for me. And I also understood why you used BCM numbering (it's impractical for me - BOARD numbering still applies not only across versions, but even for Orange Pi). I have never seen CM and had no idea about this limitation. But never mind, we'll deal with it somehow. I'll probably have to make a special version for CM. Sorry, but this will take some time...

    First I'll just do a test version where the DC and RES pins will be hardwired by software (other pins are HW controlled so it's always hardwired). Later I will add the option to choose DC and RES in the configuration dialog. Do you have any preferences as to which GPIO the DC and RES pins should be connected to in the first stage?

  • OLEDproc Add-on

    I'm not sure, but it looks like you previously had an older version installed that was still without SPI support. I forgot to write that in that case the old version must be uninstalled (including settings). Maybe it wasn't, but in any case I recommend doing a clean install. This means uninstalling the add-on (including settings) and only then installing the new version. And I would even recommend restarting Kodi after uninstalling the addon.

    After a new installation of the add-on, the configuration dialog opens automatically. Make the necessary settings and confirm by pressing OK.

    It's also a good idea to use the Dependencies button to check that all necessary plugins are installed.

    If the installation succeeds and no error is reported, it should start working. The first sign that everything is fine is the LE logo on the display. If it appears, the data configured in the LCD.xml file should be visible in a moment. If it takes a while, it can be speeded up by disabling and re-enabling the XBMC LCDproc add-on.

  • OLEDproc Add-on

    BOARD numbering is used in the add-on configuration. Pin number 25 is GND so it cannot be in the pin selection menu. I recommend using the wiring whose table is visible when you work with the add-on.

  • OLEDproc Add-on

    The time has come to publish the result of my efforts. From today, the OLEDproc add-on supports displays with both types of interfaces (I2C and SPI).

    I am developing the plugin on an SBC Orange Pi (SoC Allwinner). Fortunately, I can use these boards without restrictions and have an easily accessible GPIO connector. It's completely different with the RPi4 board. I can only borrow it for a short time and I have to disassemble the box to get to the GPIO connector.

    Unfortunately, it turned out that there were a number of difficulties to overcome to get the SPI interface working on the Orange Pi SBC, which is why it took me so long. In the end, however, it succeeded. But there is a small drawback - it was only possible with the LE11 system. On the contrary - on RPi boards, the add-on should work both with LE11 and LE10 (I only tried it on RPi4 with LE10).

    I created a total of 6 SW packages that contain the necessary files. Two for Orange Pi boards (one for H3 boards, one for H6 boards) and four for RPi boards: RPi4-LE10, RPi2-LE10, RPi4-LE11, RPi2-LE11.

    Since the SW packages exceed the allowed size, it was not possible to attach them here. So I saved them to my google drive.

    Note 1.

    The following text talks about (in the case of RPi) editing the config.txt file or (in the case of OPi boards) editing the /flash/extlinux.conf file and adding overlay files to the /flash/overlays directory. All described files and directories are located in the flash partition, which is mounted as read only in normal operation.

    Here you can read how to proceed. Although the manual only talks about the config.txt file, the procedure is exactly the same for OPi boards.

    Note 2.

    The add-on is capable of displaying texts in Kodi's native encoding (UTF-8). Unfortunately, the official version of the XBMC LCDproc add-on does not support this encoding at this time. The modification is very simple and I asked the author to include it in the official version. Before that happens, please download the modified version here.

    Installation instructions:

    1. Enable I2C or SPI interface (this of course depends on your display type)

    1.1 RPi

    1.1.1 I2C interface

    In the case of RPi, the I2C interface must be enabled by adding rows to the config.txt file.

    dtparam=i2c1=on

    dtparam=i2c_arm=on

    1.1.2 SPI/spidev interface

    In the case of RPi, the SPI interface must be enabled by adding row to the config.txt file.

    dtoverlay=spi0-1cs

    1.2 OPi H3

    1.2.1 I2C interface

    In this case, the file sun8i-h3-i2c0.dtbo should be stored in the /flash/overlays directory and the line FDTOVERLAYS /overlays/sun8i-h3-i2c0.dtbo should be added to the extlinux.conf file.

    1.2.2 SPI/spidev interface

    In this case, the file sun8i-h3-spi-spidev0.dtbo should be stored in the /flash/overlays directory and the line FDTOVERLAYS /overlays/sun8i-h3-spi-spidev0.dtbo should be added to the extlinux.conf file.

    1.3 OPi H6

    1.3.1 I2C interface

    In this case, the file sun50i-h6-i2c0.dtbo should be stored in the /flash/overlays directory and the line FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo should be added to the extlinux.conf file.

    1.3.2 SPI/spidev interface

    Depending on the specific board type, you need to choose the right overlay file. Here is an example for the OPi 3 and OPi Lite 2 boards:

    In the case of OPi 3, the file sun50i-h6-spi-spidev1.dtbo should be stored in the /flash/overlays directory and the line FDTOVERLAYS /overlays/sun50i-h6-spi-spidev1.dtbo should be added to the extlinux.conf file.

    In the case of OPi Lite 2, the file sun50i-h6-spi-spidev0.dtbo should be stored in the /flash/overlays directory and the line FDTOVERLAYS /overlays/sun50i-h6-spi-spidev0.dtbo should be added to the extlinux.conf file.

    2. Installing add-ons (install in the order listed)

    2.1 RPi

    2.1.1 Raspberry Pi Tools

    Add-ons - Install from repository - LibreELEC Add-ons - Program add-ons - Raspberry Pi Tools

    2.1.2 Add-ons from the attached SW package

    script.module.cbor2

    script.module.smbus2

    script.module.spidev

    script.module.luma

    service.oled

    In the case of the service.oled add-on, a configuration dialog opens immediately after installation.

    According to the type of your display, fill in the data in the Display and Connection tabs.

    2.1.3 Modified XBMC LCDproc addon

    After installing the add-on (from the downloaded zip file), open the configuration dialog and in the first tab (Behaviour) turn on the Use alternate charset switch. Then set the Charset to UTF-8.

    2.2 OPi

    2.2.1 Add-ons from the attached SW package

    script.module.cbor2

    script.module.smbus2

    script.module.spidev

    script.module.luma

    virtual.opi-tools

    service.oled

    In the case of the service.oled add-on, a configuration dialog opens immediately after installation.

    According to the type of your display and SBC, fill in the data in the Display and Connection tabs. On the Connection tab - don't forget to select the type of your SBC.

    2.2.2 Modified XBMC LCDproc addon

    After installing the add-on (from the downloaded zip file), open the configuration dialog and in the first tab (Behaviour) turn on the Use alternate charset switch. Then set the Charset to UTF-8.

    If the display is properly connected and all data is set correctly, the display should work at this point.

    The content of the display is (thanks to the use of the XBMC LCDproc add-on) customizable by editing the LCD.xml file. You can find the documentation here.

  • How to enable spidev interface on SoC Allwinner?

    Quote from jernej

    No, there is no DT bug.

    OK - you're right, my reasoning was wrong.

    Quote from jernej

    It's customary to have two pin groups, one for communication pins (MISO, MOSI, SCK) and another for CS pin.

    I agree, it probably has its reasons. But I wonder why Allwinner H3 (certainly e.g. Orange Pi PC) has it differently (all pins including CS are in one group).

    Quote from jernej

    CS pin can be basically any GPIO pin, not only that from SPI controller.

    I don't think that's entirely accurate. For Allwinner H6, there is always only one HW pin (for SPI0 it is PC5, for SPI1 it is PH3). See datasheet. Yes, additional CS pins can be added using the overlay, but they are no longer HW, but SW pins. I don't need to add more pins, one SPI device is enough for me.

    Quote from LuRu

    ... Or to solve the problem in a different way - more professionally (that is, make sure that the reference to the CS pin is not missing in the fdt file).

    I knew that my solution was actually a workaround. However, now I've learned a lot about overlays and I've finally done it!

    This is what the fdt file snippet looks like after applying my new overlay and it actually works with the original dtb (without any patches).

    So the only problem was that I couldn't find a working overlay anywhere and I had to create it myself.

    Here is the (source) overlay, tested on an OPi Lite2 board: sun50i-h6-spi-spidev0.dts.zip

  • How to enable spidev interface on SoC Allwinner?

    It took me several tens of hours, but I finally have some results...

    On the Orange Pi PC board, I got the OLEDproc add-on with the SPI interface up and running very quickly, without any problems. I then moved on to the Orange Pi Lite 2 board. Unfortunately there were problems there. Although the interface /dev/spidev0.0 existed, the display showed nothing. I was looking for why. I suspected the spidev add-on at first, but a test using loopback showed that spidev is fine. So I had to focus on CS, DC and RST signals. I even made a (very improvised) logic analyzer and found that the problem was in the CS signal (it was permanently connected to the logic one level). I tried to (on display) connect the CS signal permanently to GND and the display started showing! Although somewhat distorted, but still. So it was confirmed that the problem is in the non-functioning CS signal. I have now begun to investigate why this is so. I thought I'd try how it works with Armbian. I was surprised that it behaved exactly the same. I seem to have run into some bug in DT that is common to multiple OSes...

    I compared the fdt and dts files of the H3 and H6 boards and it occurred to me that the problem is that (for the H6 boards) the reference to the CS pin is missing in the fdt file.

    Here is a snippet from the decompiled fdt file:

    I believe it should look something like this correctly:

    Unfortunately, I haven't figured out a way to fix it. That's why I did it in a different way - I tried (using a patch) to modify the dts/dtb file in the same way as it is done with the H3 boards (that is, the CS pin does not have a separate node, but it is in a common node with the other signals) and it showed hope it helps!

    At first I just made a patch, modifying the "sun50i-h6.dtsi" file. However, the compilation ended with an error (in the file "sun50i-h6-pine-h64.dts" there was a reference to a missing node with a CS pin). So I had to make another patch that addressed this. Unfortunately, I don't own a pine-h64 board and I don't know if this will have any consequences for it.

    The next step was a test with the Orange Pi 3 board. It turned out that it behaves exactly the same as the Lite 2 board. This is logical, because the file "sun50i-h6.dtsi" is common to several boards. The corrected dtb file (with the help of a patch) also helped here.

    @jernej: Can you apply these patches in the official (currently nightly) release? Or to solve the problem in a different way - more professionally (that is, make sure that the reference to the CS pin is not missing in the fdt file). The non-functioning CS pin on the H6 family makes it impossible to use displays with an SPI interface.

    patches.zip

  • SoC family dependent dependency

    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)

  • SoC family dependent dependency

    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.

  • SoC family dependent dependency

    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?