search

rstrouse / relayEquipmentManager

A hardware controller for GPIO, I2c, SPI, and generic devices.
GNU General Public License v3.0
38 stars 19 forks source link

Smartfan v6 and Bookworm OS Support #65

Closed sberkovitz closed 5 months ago

sberkovitz commented 6 months ago

This PR adds support for Sequent Systems Smart Fan v6, along with support for Raspi OS Bookworm on a 4B.

The v6 Smart Fan uses a different GPIO pin from previous generations, and also lacks the capabilities drop from v4 onward. As I don't have an older device to test with, I opted to create a new module for this generation instead of sharing the existing one. This new module only contains the capabilities of the v4 and onward, and supports the changed GPIO pin in v6 (?). Some other general fixes as well.

Raspberry Pi Bookworm changes how GPIO pins are addressed. Per @rstrouse in rstrouse#61 (comment)

I have found why your GPIO numbers seem so strange. The pi engineers are now identifying gpios by touple which includes the chip id (2) in the gpio. Honestly, this is the same approach as other boards such as the orange pi and probably what raspberry should have been doing all along. Perhaps there is a future for multiple gpio headers on the same board. For now the problem is that the pi 5 does not have the gpio chip embedded (chip id 0). It is external to the cpu on chip id (2).

To address this, I have included a new pinout profile that I have tested with the Raspberry 4B. I am almost certain the 5 will need a different pinout, but unsure of other 4 variants and earlier.

rstrouse commented 5 months ago

I'll have a look. I wonder if we can detect the OS version and simply add the chip id.

rstrouse commented 5 months ago

I am going to merge this then start working on converting the whole thing to gpiod. Unfortunately, in my reading it is a bit of a cluster****. While the talking heads on various forums act as if gpiod was the standard for years it is simply not true for the raspberry pi.

These are the same discussions that were going on with wiringPi several years ago with boneheads flapping about how wiringPi should be used instead of sysfs then a few years ago the same thing with pigpio. So glad I didn't go there. In the end the chip id goofiness boils down to engineering where the default register in the line was set to the user chip id. Now it needs to be set manually. Sadly, the libgpiod libraries at this point do not appear have functioning interrupts... Yikes!

Raspberry Pi 5 represents a new challenge in that the chip id in the touple has changed once again to an external GPIO chip that is not on the SoC. To make matters worse I haven't found a reliable way of detecting the hardware version for the pi. At least a way that is cross-platform.

In the end this is going to lead to a huge number of software packages that just do not work anymore. Even, worse it will lead to a developer community that no longer wants to participate in the stupidity.