Add support for NanoPi

[ChristianSchwarz]

I would be nice if pi4j supports NanoPi's ARM Boards

Maybe these links help with the integation of wiringpi:

• http://www.orzalabs.tech/2016/08/15/wiringpi-library-on-nanopi-m1/
• http://www.friendlyarm.net/forum/topic/6797
• https://github.com/wertyzp/WiringNP

[savageautomate]

Looks interesting!

[nicktencate]

this would be great. we're replacing our raspberrypi's with nano pi neo and this means we could use the same software :)

[pezi]

Hi!
Today I finished the first build of a Pi4J version for the NanoPI M1. Probably this version will also work for NanoPI Neo and Nano Pi air. A simple test with a double color led works fine. In the next days I will try to finish all the open tasks:
NanoPiPin.java
I2C-Handling
System information

[bluexmas]

NanoPi NEO Air - WiringNP, pi4j

http://bluexmas.tistory.com/611
http://bluexmas.tistory.com/612
http://bluexmas.tistory.com/614
http://bluexmas.tistory.com/623

[pezi]

Hi!

This is my fork
https://github.com/pezi/pi4j.git
which inludes the initial changes for the NanoPi platform. In the next time I will improve the support for the NanoPi - testing is ongoing.

Complete build:
https://treedb.at/data/db/pi4j-1.2-SNAPSHOT.zip

Peter

[RebieKong]

It doesn't working well with my NanoPi NEO Plus2.
Because of there are both 64bit system and 32bit system are working with NanoPi,
I think there should be two so file.

[savageautomate]

@pezi

I have included experimental support for NanoPi in the master branch and in the current 1.2-SNAPSHOT builds. I have basically taken most of your edits and added them to the project. I did change the source repository for WiringNP to: https://github.com/friendlyarm/WiringNP

This wiki pages suggests that this repository is newer and included support for more of the NanoPi variants. http://wiki.friendlyarm.com/wiki/index.php?title=WiringNP:_NanoPi_NEO/NEO2/Air_GPIO_Programming_with_C&redirect=no

I suspect that the NanoPiPin class may need significant updates (or multiple variants) to be compatible to the different NanoPi flavors/boards.

While NanoPi support has been added to the Pi4J builds, please note that it has not been tested and should be considered experimental.

Thanks, Robert

[savageautomate]

@RebieKong ,

Please note you are welcome to try the latest 1.2-SNAPSHOT builds on your NanoPi, but the WiringNP project does not explicitly mention the NEO Plus 2 board on the README, so the WiringNP project may not support it (yet?).

Also note the current Pi4J builds are not including any compiled native libraries for 64 bit systems yet. You would have to compile the pi4j-native project on your 64 bit system and then recompile pi4j-core to include your 64-bit artifacts.

Thanks, Robert

[RebieKong]

@savageautomate
I try to build @pezi 's code by myself,it works.
WiringNP supports Neo Plus2 board but is doesn't written on the README.
I just thinking about if these is necessary to set both 32 bit version and 64 bit version for NanoPi Like
nanopi-64 and nanopi-32.

[pezi]

@savageautomate
Thanks for the changes. After my hints on the FriendlyArm forum that the WiringNP Version is out of date in comparison to the original project FriendlyArm updated and splited their WiringNP forks according their new models. This changes are not includes in my fork.

But I see two problems - for each Neo Model model a tailored WiringNP version is necessary to satisfy the different GPIO/hardware layout. But a .so file per model would blow up the jar file size (1). The differences between the WiringNp versions are minimal - fix coded GPIO arrray definitions. Passing a paramter per JNI to the WiringNP lib to select the correct GPIO definition arrrays

But there is also the problem, it seems there is no reasonable method to detect the underlaying hardware, to detect the correct NanoPi version. The user must select the correct model per API.

[savageautomate]

@pezi

But I see two problems - for each Neo Model model a tailored WiringNP version is necessary to satisfy the different GPIO/hardware layout. But a .so file per model would blow up the jar file size (1).

You are correct. There is a separate (WiringNP) branch for each each "family".
I do hate this and it does force a separate native build and .so file for each.
Sadly this seems to be a common pattern in other projects such as BananaPi as well.

This does start to bloat the JAR since we currently embed the SO files. So it's not a sustainable pattern. We could switch to only compiling against the shared lib interface of WiringPi, but again sadly not all derivative projects such as WiringNP stay in sync with the official WiringPi APIs.

But there is also the problem, it seems there is no reasonable method to detect the underlaying hardware, to detect the correct NanoPi version. The user must select the correct model per API

Yes, this is unfortunate as well. This forces the user to deal with it in code. Maybe Pi4J needs to break up it's platform support into individual platform packages where the user must install or include the correct platform package for the targeted platform rather than having to choose it from an API?

Thoughts?

Thanks, Robert

[RebieKong]

@savageautomate
So, can we refer to the Apache Beam approach?
Like: beam-runners-spark, beam-runners-flink_2.10
This distinguishes some dependencies, and developers need to choose the dependencies and pack them up at the time of development

[HanSolo]

Any chance to make it work on a NanoPi Duo?