PI 5 8GB incompatible

[CStracha]

The documentation state PI 5 is supported, however PI 5 hardware changes appear to require libgpiod rather then pigpio.

benkuper/Chataigne#214

Sep 20 10:13:16 rowingmonitor npm[1593]: ==== Open Rowing Monitor 0.9.0 ====
Sep 20 10:13:16 rowingmonitor npm[1593]: bluetooth profile: FTMS Rower
Sep 20 10:13:16 rowingmonitor npm[1593]: Starting a just row session, no time or distance target set
Sep 20 10:13:16 rowingmonitor npm[1593]: heart rate profile: Off
Sep 20 10:13:16 rowingmonitor npm[1593]: ant plus profile: Off
Sep 20 10:13:16 rowingmonitor npm[1593]: webserver running on port 80
Sep 20 10:13:16 rowingmonitor npm[1617]: 2024-09-20 10:13:16 gpioHardwareRevision: unknown rev code (d04170)
Sep 20 10:13:16 rowingmonitor npm[1617]: 2024-09-20 10:13:16 initCheckPermitted:
Sep 20 10:13:16 rowingmonitor npm[1617]: +---------------------------------------------------------+
Sep 20 10:13:16 rowingmonitor npm[1617]: |Sorry, this system does not appear to be a raspberry pi. |
Sep 20 10:13:16 rowingmonitor npm[1617]: |aborting. |
Sep 20 10:13:16 rowingmonitor npm[1617]: +---------------------------------------------------------+
Sep 20 10:13:16 rowingmonitor npm[1617]: /opt/openrowingmonitor/node_modules/pigpio/pigpio.js:54
Sep 20 10:13:16 rowingmonitor npm[1617]: pigpio.gpioInitialise();
Sep 20 10:13:16 rowingmonitor npm[1617]: ^
Sep 20 10:13:16 rowingmonitor npm[1617]: Error: pigpio error -1 in gpioInitialise
Sep 20 10:13:16 rowingmonitor npm[1617]: at initializePigpio (/opt/openrowingmonitor/node_modules/pigpio/pigpio.js:54:12)
Sep 20 10:13:16 rowingmonitor npm[1617]: at new Gpio (/opt/openrowingmonitor/node_modules/pigpio/pigpio.js:158:5)
Sep 20 10:13:16 rowingmonitor npm[1617]: at createGpioTimerService (file:///opt/openrowingmonitor/app/gpio/GpioTimerService.js:40:18)

[JaapvanEkris]

Thanks for reporting this. I'll look into it (my own Pi5 just arrived). It is weird as some have reported in the past it did work, maybe pigpio made an error somewhere?

[JaapvanEkris]

Took a first look, it seems that the Pi 5 has a different GPIO architecture, which stops pigpio: joan2937/pigpio#589

This puts us on a crossroad: the pigpio library has some features we really need (like a nano-second level debounce filter, and nanosecond precission) which weren't found in other libraries (see also laberning#85 ).

I am proposing to drop the claimed RPi 5 support for now, and see what library matures in the coming year that supports the gpio features we need.

[CStracha]

For consideration the onoff library supports interrupt driven DIO callbacks and appears to accept sub millisecond debounce timings.
I used the onoff library on a RPI5 with a Viking Rower AR, (water rower), successfully, (sensor on the paddle spindle). The RPI5 was running 6.6.47+rpt+rpi+2712, there also appears to be issues with the kernel releases and gpio chip numbering along with RPI hardware changes. The ORM code changes required were very minimal to swap to onoff.

[Abasz]

Onoff was used originally with ORM. But its not as accurate as pigpio. Its not interrupt based either (nor is pigpio though) in the traditional sense. Both do polling of the state basically. Onoff reads the filesystem basically and the code is mostly nodejs based (apart from epoll that is provided by Linux basically for monitoring file system changes), which efficiency you can imagine...:). Basically onoff can do several thousands, pigpio can do hundreds of thousands of interrupts per second (this is due to the fact hat pigpio is a C library under the hood, it is very, very efficient and there is just a simple nodejs wrapper around it).

But the main advantage of pigpio over onoff is that pigpio exposes the exact timestamp (in microseconds) of the state change of the pin, while onoff does not. Which means that in the case of onoff we have only an approximation of the time when the sensor was triggered. Before we can read the time the whole thing will go through several layers that ads to latency. Also the time we read will depend on the execution of the JS code, the filesystem, the accuracy of the epoll etc. (i.e. when the CPU has time to deal with these things) that creates a fully random error in the deltaTime data and reduces accuracy.

Please see discussion Jaap posted above, it has all the details on why this descision was made: laberning#85

In my view onoff is no alternative (though probably his new algorithm would be able to handle the increased latency error better than the algorithm back in 2022).