#642 Add hardware detection with FFM plugin

[DigitalSmile]

New hardware detection system. Consists of steps:

1. Look at alive interfaces in /dev and PWM
2. Look at device tree to determine "disabled" interfaces
3. Fallback to ACPI if nothing found

I put this in FFM plugin right now, not to mess up with dependencies in pi4j-core. When it will be in core we can decide how to move this functions.

Example output (rpi5):

13:45:01.210 [main] DEBUG com.pi4j.plugin.ffm.FFMPlugin - FFM plugin hardware detection:

Hardware I/O detection
  Board       : Raspberry Pi
  Kernel      : 6.8.0-1057-raspi
  Device tree : present

  State   Subsystem  Identifier               Driver                   Details
  ──────  ─────────  ───────────────────────  ───────────────────────  ─────────────────────────────────────────────────────────────────────────────
  ACTIVE  GPIO       /dev/gpiochip0           gpio-brcmstb@107d508500  name=gpiochip0, lines=32
  ACTIVE  GPIO       /dev/gpiochip1           gpio-brcmstb@107d508520  name=gpiochip1, lines=4
  ACTIVE  GPIO       /dev/gpiochip2           gpio-brcmstb@107d517c00  name=gpiochip2, lines=15
  ACTIVE  GPIO       /dev/gpiochip3           gpio-brcmstb@107d517c20  name=gpiochip3, lines=6
  ACTIVE  GPIO       /dev/gpiochip4           pinctrl-rp1              name=gpiochip4, lines=54
  ACTIVE  I2C        /dev/i2c-1               -                        Error: Device '/dev/i2c-1' (root:dialout) does not belong to group 'i2c'.
  ACTIVE  I2C        /dev/i2c-13              -                        Error: Device '/dev/i2c-13' (root:root) does not belong to group 'i2c'.
  ACTIVE  I2C        /dev/i2c-14              -                        Error: Device '/dev/i2c-14' (root:root) does not belong to group 'i2c'.
  ACTIVE  SPI        /dev/spidev0.0           -                        Error: Device '/dev/spidev0.0' (root:dialout) does not belong to group 'spi'.
  ACTIVE  SPI        /dev/spidev0.1           -                        Error: Device '/dev/spidev0.1' (root:dialout) does not belong to group 'spi'.
  ACTIVE  SPI        /dev/spidev10.0          -                        Error: Device '/dev/spidev10.0' (root:root) does not belong to group 'spi'.
  ACTIVE  PWM        /sys/class/pwm/pwmchip0  107d517a80.pwm           2 channels

And GPIO related:

13:45:01.212 [main] TRACE com.pi4j.plugin.ffm.FFMPlugin - GPIO details:

  GPIO /dev/gpiochip0 line map:
    Offset  Pin  Name            Used
    ──────  ───  ──────────────  ────
    0       27   -               -
    1       28   2712_BOOT_CS_N  yes
    2       3    2712_BOOT_MISO  -
    3       5    2712_BOOT_MOSI  -
    4       7    2712_BOOT_SCLK  -
    5       29   -               -
    6       31   -               -
    7       26   -               -
    8       24   -               -
    9       21   -               -
    10      19   -               -
    11      23   -               -
    12      32   -               -
    13      33   -               -
    14      8    PCIE_SDA        -
    15      10   PCIE_SCL        -
    16      36   -               -
    17      11   -               -
    18      12   -               -
    19      35   -               -
    20      38   PWR_GPIO        yes
    21      40   2712_G21_FS     -
    22      15   -               -
    23      16   -               -
    24      18   BT_RTS          -
    25      22   BT_CTS          -
    26      37   BT_TXD          -
    27      13   BT_RXD          -
    28      -    WL_ON           yes
    29      -    BT_ON           yes
    30      -    WIFI_SDIO_CLK   -
    31      -    WIFI_SDIO_CMD   -

[stefanhaustein]

Generally, I'd really prefer if we could first have a discussion about what data structure(s) we publicly expose to the user, depending on what's doable with ffm.

IMHO, this could just be a list of available busses/pins per IO type (i2c, spi, ...)

Also, we might want to check if we are aligned on the purpose here.

My goal when bringing up this topic was to allow generic pi4j-based software to prevent users from selecting hardware parameters outside the physically available ranges.

[stefanhaustein]

Where does this information come from?

[DigitalSmile]

From documentation of different boards. Claude helps me to bring this all together.

[DigitalSmile]

Generally, I'd really prefer if we could first have a discussion about what data structure(s) we publicly expose to the user, depending on what's doable with ffm.

Let's discuss, this PR is just an attempt to bring some debugging information to the user during startup. It does not mean we cannot expose something to the user with API in structured manner.

IMHO, this could just be a list of available busses/pins per IO type (i2c, spi, ...)

I did it sometime ago... But I do not think anybody used it separately with specific API calls. I think library startup is a good place to give a user an overview on what is available.

Also, we might want to check if we are aligned on the purpose here.
My goal when bringing up this topic was to allow generic pi4j-based software to prevent users from selecting hardware parameters outside the physically available ranges.

Can you provide any examples? May be we need to be more specific in checks and exceptions during runtime?

[sonarqubecloud]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud