Decoupling WiringPi


  • administrators

    I'm considering further decoupling the WiringPi dependency and wrapped interfaces/APIs. What I mean is that I may potentially break up the pi4j-core project into something that separates user facing APIs from the WiringPi implementation:

    • pi4j-api
    • pi4j-rpi-wiringpi

    My goal would be to decouple both platform specifics (RaspberryPi) and I/O implementation (WiringPi) from the Pi4J APIs. This could allow for alternate platform implementations (outside of the core Pi4J project) as well as alternate I/O implementations.

    Thoughts?


  • Contributor

    Sounds like a good idea to me.


  • administrators

    I think as part of this effort, I would also like to get rid of hard-coded/pre-defined/enumerated pins (RaspiPin.java ,etc).
    This becomes burdensome to maintain as new models and various board revisions evolve. Additionally with the ComputeModule, it does not follow the WiringPi pin numbering scheme . So with that said, I think I'm suggesting to ditch the old WiringPi numbering scheme as well. Other I/O libraries (apart from WiringPi) don't follow this convention.

    So a new pin interface may just require a simple numerical pin argument to provision the pin. Perhaps any pin validation can be implemented in the platform/hardware impl layer.


  • administrators

    Perhaps something along these lines. An API layer, a platform abstraction layer, and a hardware implementation/provider layer.

    eb17bd6a-a626-4886-80d7-0d2f1806cde7-image.png

    I was thinking that the hardware provider layer could be swapped out/configured at runtime on the target platform for the specific impl needed. Using WiringPi or any other implementation method/library. This would certainly make it easier to replace WiringPi if a better library is available down the road. In fact, I think we already implement our own I2C and SPI layers and no longer use WiringPi for that.



  • This looks promissing.
    The abstraction from the platform may also allow writing easier Unit tests for the pi4j-platform-rpi.jar.
    Maybe an pi4j-provider-api.jar would be nice for decoupling. By the way I think the Module/Maven combination will force it anyway considering JDK11 support.

    What about a pi4j-plattform-logging.jar which encapsulates the used logging framework. You might also just use slf4j, but my experience is that having your own place for future adaptions to logging is always paying off.

    By the way, it is really nice to have you back and active. :+1:


  • administrators

    @albahrani said in Decoupling WiringPi:

    By the way, it is really nice to have you back and active. :+1:

    Thanks!



  • As I totally agree maintainability and testability should have focus, I still want to point out that the RaspiPin's actually provide a lot of useful info about the pins, addresses, capabilities, etc.

    Based on those RaspiPin's and some small extra code in the core-module I was able to define header info per Pi-boardtype.
    See https://github.com/Pi4J/pi4j/pull/458 & https://github.com/Pi4J/pi4j/pull/458/files#diff-0b1a656a642b9ef7a097e61f7f5c5c0e > RaspiPin.getHeader(SystemInfo.BoardType board)

    Video on: https://webtechie.be/2019/05/23/pi4j-extending-with-a-javafx-info-application

    It enabled me to quickly make a JavaFX UI which I later would like to couple to the REST interfaces. See screenshot in https://github.com/Pi4J/pi4j/issues/450.

    Just my 2 cents...

    FDelporte created this issue in Pi4J/pi4j

    open Add PIN list for different boards #450


  • Contributor

    @FDelporte

    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.


Log in to reply