Posts by LuRu

  • 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?

  • How to enable spidev interface on SoC Allwinner?

    Quote from jernej

    I have no idea why it doesn't work on LE10 H3 image. Can you confirm that you actually get other issues like those described before?

    I'm sorry, but I don't understand what you mean. To be sure, however, I performed a new clean installation of the latest LE10 nightly and reapplied the overlay. Without success.

    I'm happy to report another partial success:

    With the latest nightly LE11, /dev/spidev1.0 already exists on OPi3 (H6)!

    Conversely, even with the latest nightly LE10, there is no /dev/spidevX.X (neither H3 nor H6).

    It occurred to me that it might help to find the cause when you see the result of the find /sys/ -name '*spi*' command.

    So I did it for all four cases. The result is in the attachment.

    However - it is no longer absolutely necessary to solve it for LE10. I can continue to develop the OLEDproc add-on on LE11. But of course it would be better if it worked for LE10 as well.

    find-sys-name-spi.zip

  • How to enable spidev interface on SoC Allwinner?

    I have other findings:

    1. I installed nightly OPi-PC-LE10. Result: no spidev

    2. I decompiled the FDT files (they are attached). It looks like it should work, but it doesn't work.

    3. Due to the behavior on OPi-PC (works with nightly LE11, but not with nightly LE10), I also tried a clean installation of nightly LE11 on OPi-3. Result: no spidev

    What are we going to do next?

    OPI-FDT-ALL.zip

  • How to enable spidev interface on SoC Allwinner?

    I report partial success!

    Today's nightly LE11 Orange Pi PC is already working - /dev/spidev0.0 has appeared.

    But on SoC H6 I'm still without spidev. I also tried a fresh installation of LE11 on a clean SD card, but nothing. I even tried it on two boards (Pi 3 and Pi LIte 2), but in vain.

    I also wanted to try my own build LE 10 on the OPi PC, but it won't start at all - see the picture. Until recently, however, I did the building without any problems - I have no idea what is wrong (whether the problem is on my side).

  • How to enable spidev interface on SoC Allwinner?

    1. mount -o remount, rw / flash

    2. I copy the file sun50i-h6-spi-spidev1.dtbo to the directory /flash/overlays

    3. I edit the file /flash/extlinux/extlinux.conf and in the line FDTOVERLAYS I add the parameter /overlays/sun50i-h6-spi-spidev1.dtbo

    4. mount -o remount, ro / flash

    5. reboot

    Note:

    My extlinux.conf file looks like this:

    Code
    LABEL LibreELEC
LINUX / KERNEL
FDT /sun50i-h6-orangepi-3.dtb
FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo /overlays/sun50i-h6-spi-spidev1.dtbo
APPEND boot = UUID = 0908-1419 disk = UUID = 8cd4f88f-17df-48ce-bec6-cca1eb844534 quiet console = ttyS0,115200 console = tty1

    sun50i-h6-spi-spidev1.dtbo.zip

  • How to enable spidev interface on SoC Allwinner?

    Above all - thank you for your patience with me.

    In the meantime, I tried a modified overlay (with the string "dh, dhcom-board") on H6. But unfortunately, without success. So CONFIG_SPI_SPIDEV is probably not the only problem.

    Note:

    1) If I do image bulding myself, can I create an image (where CONFIG_SPI_SPIDEV will be allowed) for H3 as well?

    2) In the future - is it possible to enable CONFIG_SPI_SPIDEV for H3 in the official version? It's a pretty common thing to connect a display to Kodi, so why can't it be with a spi interface?

    Not everyone will be able to build a WiFi version.

  • How to enable spidev interface on SoC Allwinner?

    Quote from jernej

    Not sure what problem you see with compatibles - all 5.10 versions I checked have same compatible array.

    I did not say the opposite. I probably wrote it somehow confused, I'm sorry.

    So once again. I used the string "ge, achc" as the first attempt and it didn't work (in LibreELEC). I wanted to verify that it works at least in Armbian. But it didn't work. That's why I looked at what Linux is in Armbian. There is 5.15.43. So I looked in the appropriate spidev.c file and there I found that the compatible array does not contain the string "ge, achc". So I used the string "dh, dhcom-board", which is found in both versions. Then I tried it in both Armbian and LibreELEC. It worked in Armbian, it didn't work in LibreELEC.

    Quote from jernej

    I just noticed that CONFIG_SPI_SPIDEV is not even enabled for 32-bit AW SoCs, but it is for 64-bit. So it should work on H6, but not on H3.

    How do I understand that? This means that for H3 there is no chance for it to work in LibreELEC (in Armbian it works!).

    I'll try to see if it really works at least on H6.