Add support for NanoPi #279
Comments
Looks interesting! |
this would be great. we're replacing our raspberrypi's with nano pi neo and this means we could use the same software :) |
Hi! |
NanoPi NEO Air - WiringNP, pi4j http://bluexmas.tistory.com/611 |
Hi! This is my fork Complete build: Peter |
It doesn't working well with my NanoPi NEO Plus2. |
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 |
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 |
@savageautomate |
@savageautomate 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. |
You are correct. There is a separate (WiringNP) branch for each each "family". 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.
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 |
@savageautomate |
Any chance to make it work on a NanoPi Duo? |
Closed; Pi4J v1.4 drops support for alternate platforms to better focus on core functionality. Pi4J v2.0 will add support for abstracting platforms in a new pluggable architecture. |
I would be nice if pi4j supports NanoPi's ARM Boards
Maybe these links help with the integation of wiringpi:
The text was updated successfully, but these errors were encountered: