New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for NanoPi #279

Open
ChristianSchwarz opened this Issue Oct 12, 2016 · 13 comments

Comments

Projects
None yet
7 participants
@ChristianSchwarz

ChristianSchwarz commented Oct 12, 2016

@savageautomate

This comment has been minimized.

Member

savageautomate commented Oct 12, 2016

Looks interesting!

@nicktencate

This comment has been minimized.

nicktencate commented Jan 21, 2017

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

@pezi

This comment has been minimized.

pezi commented Mar 6, 2017

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

This comment has been minimized.

@pezi

This comment has been minimized.

pezi commented Apr 30, 2017

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

This comment has been minimized.

RebieKong commented Aug 10, 2017

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

This comment has been minimized.

Member

savageautomate commented Aug 11, 2017

@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

This comment has been minimized.

Member

savageautomate commented Aug 11, 2017

@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

This comment has been minimized.

RebieKong commented Aug 12, 2017

@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

This comment has been minimized.

pezi commented Aug 13, 2017

@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

This comment has been minimized.

Member

savageautomate commented Aug 28, 2017

@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

This comment has been minimized.

RebieKong commented Aug 29, 2017

@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

This comment has been minimized.

HanSolo commented Nov 26, 2017

Any chance to make it work on a NanoPi Duo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment