OT2 refresh: switch to libgpiod #5310
Milestone
Comments
ahiuchingau
added a commit
that referenced
this issue
Apr 7, 2020
This was referenced Apr 7, 2020
sfoster1
pushed a commit
that referenced
this issue
Apr 17, 2020
sfoster1
pushed a commit
that referenced
this issue
Apr 21, 2020
…5381) This moves our API server over to using libgpiod (https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/), the current state of the art for controlling GPIO pins in linux through a character device rather than sysfs. This should be faster, is easier to improve, and doesn't use an officially deprecated abi (https://www.kernel.org/doc/html/latest/admin-guide/gpio/sysfs.html). One key difference that drives many changes in this PR is that control over gpios through libgpiod is lifetimed to a process, and ownership over an individual gpio line is restricted to a single pid. That means that - We have a single gpio controller object instead of free functions; this has the lifetime of the main hardware controller and is passed around to other things that need it, notably the robot singleton in the robot server - Given that the hardware controller owns the object, we pushed down smoothie reprogramming into the hardware controller so that we don't have to do it in the server code, which involves multiple instantiations of hardware controller sections And finally, it means that only the robot server can control GPIOs. After this PR, protocols executed through jupyter or opentrons_execute cannot control GPIOs. closes #5310
IanLondon
pushed a commit
that referenced
this issue
Apr 22, 2020
…5381) This moves our API server over to using libgpiod (https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/), the current state of the art for controlling GPIO pins in linux through a character device rather than sysfs. This should be faster, is easier to improve, and doesn't use an officially deprecated abi (https://www.kernel.org/doc/html/latest/admin-guide/gpio/sysfs.html). One key difference that drives many changes in this PR is that control over gpios through libgpiod is lifetimed to a process, and ownership over an individual gpio line is restricted to a single pid. That means that - We have a single gpio controller object instead of free functions; this has the lifetime of the main hardware controller and is passed around to other things that need it, notably the robot singleton in the robot server - Given that the hardware controller owns the object, we pushed down smoothie reprogramming into the hardware controller so that we don't have to do it in the server code, which involves multiple instantiations of hardware controller sections And finally, it means that only the robot server can control GPIOs. After this PR, protocols executed through jupyter or opentrons_execute cannot control GPIOs. closes #5310
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To support work on the rpi GPIO interface, switch to a libgpiod-based GPIO interface instead of the deprecated /sys/class/gpio interface.
The text was updated successfully, but these errors were encountered: