@FDelporte said in Support ARM64:
@playton @dajma00 update: Robert has been working on 32 and 64-bit versions as described here https://v2.pi4j.com/build
It looks like in my effort to add 64-bit support I broke the 32-bit builds for ARMv6. (Raspberry Pi Zeros)
So, I'll have to revisit that effort to get it working on ARMv6 again :-)
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.
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.