Support for OrangePi 5/Plus

[Son-kun]

Hi, is there any plan to support other device than RPi?
I'm specifically asking about Orange Pi 5 Plus.
Currently RPi is behind in terms of computing power, so I'm forced to move to Orange and I'm trying to use GPIO on this SBC...

[taartspi]

No plans to support any SBC other than RPI. The Pi4j V2 statement is: [(https://pi4j.com/about/new-in-v2/)] v2

The following features have been removed from the Pi4J library:
Other Platforms – Other platforms such as Odroid, BananaPi, NanoPi, OrangePi, etc. have been removed and will no longer be supported.

[FDelporte]

Indeed, there are no plans. But... ;-)

As you can see on the architecture diagram, https://pi4j.com/architecture/, the design with modules does allow the creation of a package for other platforms. Only Raspberry Pi was kept as the maintenance and testing grew exponentially with each platform, and we don't have enough "power" to handle this. Of course, if someone would stand up to take up this role for a specific platform, that decision can be reconsidered.

[sbeeker]

I wanted to "attempt" to create two new "matrix" images, and wanted to know if it is okay.

1. Make a I2C version of the CrowPi basically for Coder Dojo kids.
2. Put a MAster /Slave communications concept between Hardware and Pi4J libraries I guess. Add communications effectively to distribute the devices. Example of maybe mosquito pub / sub transport between controllers and slaves for the device.

Perhaps in private email discuss.

I would work in own repos and if you see anything you like can take it back. Should be easy merge at least for the matrix build part.

Learned so much today reading all these projects. Quite impressive work!

[FDelporte]

Hi, any idea to use at CoderDojo is a good idea :-)
And, of course, please do fork or experiment in your own repos and keep us in the loop! Even if it isn't something to merge in the Pi4J repos, we can at least write about it on https://pi4j.com/featured-projects/, the blog, and/or our social media.
Have fun experimenting!!!

[oliviercoma]

I checked the source code to try and support the RK3588, (different board from the OPI 5 Plus but the same microcontroller). I had high hopes that the plugin system would make this possible.

It's a great idea, but unfortunately, the plugin system alone isn't sufficient. The core library would need substantial modifications because many elements, like BoardInfo, BoardInfoHelper, and BoardModel, are heavily dependent on non-inheritable or non-extendable classes and enums.

For example, GPIOD library could be re-used "as-is" on the RK3588 but there are multiple checks on the BoardModel (that cannot be extanded) and thus prevent the library from loading

[FDelporte]

Hi, @oliviercoma can you explain a bit more what should be extended in BoardInfoHelper?

[oliviercoma]

Hello @FDelporte,
Thanks for your response.

The private constructor of BoardInfoHelper tries to detect the board type and creates a BoardInfo. But currently, only values from enum BoardModel can be discovered with the implemented mechanism (and thus only Raspberry PIs).

getBoardName() actually works and returns correct value (Radxa ROCK 5A) in my case, but boardModel is then returned as UNKNOWN as there is no enum value for it.

I thought I could live with this, as this does not make the library crash or stop, but then GPIODContext does not work due to:

if (BoardInfoHelper.current().getBoardModel() == BoardModel.UNKNOWN) {
    logger.warn("Can't initialize GpioD context, board model is unknown");
    return;
}

Note that there are other occurences of this check (e.g. in NativeLibraryLoader.loadLibraryFromClasspath)

It could be good to have plugins that can discover board models and genericze BoardModel (and related classes Soc, Cpu), to make it an interface. HeaderVersion and others device related variables could be plugin specific in the implementation (i.e. RaspberryPiBoardModel interface extending BoardModel interface)

[FDelporte]

For multiple reasons, I wanted to try RPi-alternatives for some time now, but never got started with it. So time for the next step ;-) I just ordered an Orange Pi 5 with RK3588 and I think I have somewhere an older RK-board. I'll try to do some experiments asap with these and extend the BoardInfoHelper. It would be nice to learn how Pi4J can be used on other boards...

[oliviercoma]

Further investigation:

I've set the BoardModel as MODEL_5_B using reflection and made some progress.
I've found that GpioDContext makes the assumption that:

• All usable Gpio lines are on the same GpioChip
• The GpioChip of intereset is labelled "pinctrl".

For the RK3588S:

• There is not just one gpiochip of interest (Gpio lines are spread out on multiple cpiochips)
• The Gpiochips are labelled "gpio0", "gpio1", "gpio2", "gpio3", "rk806-gpio"

To genericize it, I see multiple solutions:

• Add argument to getOrOpenLine so that gpiochip can be passed as well
• Let plugins the abaility to define some kind of mapping
• Abstract away the concept anb use named lines e.g. from my Radxa 5A:

pi@pi-desktop:~$ sudo gpioinfo
gpiochip0 - 32 lines:
        line   0:      unnamed       unused   input  active-high
        line   1:      unnamed       unused   input  active-high
        line   2:      unnamed       unused   input  active-high
        line   3:      unnamed       unused   input  active-high
        line   4:      unnamed       unused   input  active-high
        line   5:      unnamed       unused   input  active-high
        line   6:      unnamed       unused   input  active-high
        line   7:      unnamed  "interrupt"   input  active-high [used]
        line   8:      unnamed       unused   input  active-high
        line   9:      unnamed       unused   input  active-high
        line  10:      unnamed       unused   input  active-high
        line  11:      unnamed       unused   input  active-high
        line  12:      unnamed       unused   input  active-high
        line  13:      "PIN_8"       unused   input  active-high
        line  14:     "PIN_10"       unused   input  active-high
        line  15:      unnamed       unused   input  active-high
        line  16:      unnamed       unused   input  active-high

I don't know if it's a possibility with Raspberry Pis (names are defined in Linux device tree configuration files), but it would be my preferred solution