New GPIO device to support multiple pins

[IAmNickNack]

Pi4j doesn't currently provide functionality to read/write multiple pins at a time.

A DigitalPort or similar providing this functionality could simplify integration with ICs which operate in a parallel manner. E.g.

• Writing to a 74LS138 (3 to 8 decoder) can require up to 6 output pins from the controller (minimum of 3)
• Reading/writing buffer-like devices such as 74LS245, requiring 8-9 in or out pins
• Any parallel connection to another microcontroller

The Pi4j API currently requires these types of interaction to be done in a serial-like fashion as it's not possible to read/write multiple pins at once. This adds unnecessary complication to application code.

GPIO_V2_LINE_GET_VALUES_IOCTL and GPIO_V2_LINE_SET_VALUES_IOCTL used by FFM provide these operations.

[IAmNickNack]

This would complicate any "unique check" being discussed here => #509 (comment)

[eitch]

a pi4j-driver could implement this, by handling n-pins. The performance would probably be abysmal. But the API could be clear. And in a further step we could then see how FFM could possibly supply such a feature.

[IAmNickNack]

Exactly. Because currently we have to communicate serially using multiple DigitalOut/In instances. (Unless I've missed something)

A device type capable of setting a mask value as provided by the above methods would optimise this.

[stefanhaustein]

Drivers has these:

• https://github.com/Pi4J/pi4j-drivers/blob/main/src/main/java/com/pi4j/drivers/io/expander/pcf8574/Pcf8574OutputDriver.java
• Add a driver for the PCF8574 in input mode pi4j-drivers#51

I am not super happy with some of the naming in the API, but I think the I2C IO expander case is very similar to a "local" multi-pin read and write API:

• Writing a word to I2C sets or resets multiple pins
• Reading a word from I2C informs about the state of multiple pins

Might make sense to have a shared (super-)interface here....?

EDIT: A use case is here: https://github.com/Pi4J/pi4j-drivers/blob/1bfea3c39eed383c3069c740e06db7a39bebb51b/src/main/java/com/pi4j/drivers/display/character/hd44780/Hd44780Driver.java#L95

[DigitalSmile]

Yes, when I was implementing FFM provider I was thinking the same thing. But the goal was to have a basic support, similar to other providers, until release.

This is definitely worth designing and implementing. Design considerations are understandable, I hope we can figure out how to make it usable.