succd: Switch to libgpio to ensure GPIO states are reset when succd crashes #4
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For the future, I'd like to ensure that output signals will not persist in case of a succd malfunction. Switching to libgpio would solve this nicely as a pin accessed through libgpio is reset to its default state when the file-descriptor is closed.
Seems https://github.com/warthog618/go-gpiocdev is the canon solution for this?
Having GPIO not get reset is sometimes a feature, eg. for being able to restart succd while at vacuum, without disabling the rough/high vacuum feedback lines. I would still like to have this support, at least through some sort of graceful shutdown process.
That being said, which libgpio or kernel API are you referring to here?
A quick look at this libgpio shows that this is pretty much doing the same that the code already is - opening up a sysfs file for every operation.
libgpiod and go-gpiocdev seems to be for a different kernel API (gpio chardev) that what we're using (/sys/class/gpio), and I'm not sure the BBB supports it. I think it does? But even then, looking at the relevant kernel docs there's only a mention of 'may revert to its default state', which doesn't seem like something we can rely on (What is a default state? Can we influence the 'may'? Can we change the default state? Because the on-boot default for these pins is to be high-impedance, which kinda sucks.).
libgpiod is the gpio chardev, yes. It is defined to reset on fdes closure. Supported in kernels >= 5.10.
Right, but what does it reset to? And what's your reference for this, other than the docs which state 'may' (which doesn't inspire confidence)?
To my knowledge, it should always reset to the pin configuration described in the DT. Yeah, documentation is spotty here. But it's "reliable" to the degree that using a linux-controlled GPIO for deterministic behavior is "reliable". If we want/need more, the current hardware isn't going to cut it anyway...
Hm, to me this is exactly what I don't want. The second that succd no longer actively monitors the pirani signals, the vacuum feedback lines are no longer following reality. That might be tolerable for a short interruption during a succd update/restart, but not when succd fails for a longer period of time.
If we really need the ability to update succd during an experiment, I'd rather have a second daemon taking care of sending succd output signals to GPIOs with a watchdog timeout to bridge over succd restarts.