During Code One, IBM will be talking to developers about the importance of being an open enterprise, covering open source, open standards, and open governance as the future of development. At CodeOne this emphasis on Open will be focused primarily on key Java open projects, including Jakarta EE, MicroProfile, Open Liberty, Open J9, Spring; and the supporting cloud platform projects including Kabanero, Istio, Appsody, Eclipse Codewind, and Razee.
web development services
I have started moving forward with the PIGPIO library. It allows for a direct shared C lib, pipes and socket integration. So this seems to be a nice solution to gain the remote I/O access that I wanted to support in Pi4J 2.0 without having to re-invent the wheel.
I'm starting with the socket integration as it should allow for faster development and testing cycles. It of course will be slower than a direct native integration, but we can add that once Pi4J 2.0 is up and working.
I am trying to get this up and running on an odroid n2 but getting an error regarding architecture and suspect this might be my issue so I would say yes, please create a ARM64 build. HardKernel/Odroid has a wiring pi version they have made they say works with the N2 so I would assum it is 64 compatible.
java.lang.UnsatisfiedLinkError: /tmp/libpi4j101115299716273614.so: /tmp/libpi4j101115299716273614.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
In version 2, I want to get away from hard coding a pin class/enum for each Raspberry Pi model or alternate hardware platforms. With that being said, there is some value in discoverability of available pins and its supported functionality. I'm thinking of some sort of configuration based data file for each hardware model that describes the platforms capabilities but does not require compiling directly into the Pi4J sources. The Pi4J library could provide APIs that allow you to discover and validate any given I/O pin for the platform it's running on. It would need to be runtime extensible to support augmented functionality via GPIO/PWM expander chips, etc.
Im not suggesting that I have this figured out yet, but it's just a goal/thought at this point.
Furthermore on this same topic I want to get away from hard-coding boards and board info in the same manner.
So perhaps some sort of platform config file describes all the Pi4J enabled capabilities for each hardware platform/model.