I want to know please, how the MuxControl sample works https://github.com/mangOH/MuxControl, and what is the difference with GpioExpander… when i see the source code i think that MuxControl is the old version of GpioExpander … it’s true ??
If we use both apps is the same time… in the case, both apps use the same gpioexp can that create a conflict issue?
Hi @dfrey, any clarification, please
Hi @mehdi.ALL,
The mangOH Green has 3 GPIO expanders on the I2C bus. In the 3.18 and 3.14 kernels that we have on the WP modules, the standard way to access GPIO from userspace is using the “gpiolib” functionality of the kernel. It’s somewhat confusingly named since it isn’t a library at all. It is a way of exposing GPIOs via a filesystem API under /sys/bus/gpio/.
At some point in the past, someone at Sierra Wireless decided it would be a good idea to insert a mapping feature into the kernel. What this does is intercept writes such as echo 37 > /sys/class/gpio/export and performs a lookup. 37 is expected to be the CF3 GPIO number which is not something that the kernel really understands except that this mapping table has an entry that says “37 is really GPIO 85”. It hides this fact from the user and creates /sys/class/gpio/gpio37. The user can then use this GPIO from userspace without knowing that they are actually using what the kernel calls GPIO 85. Note that I have made up the numbers 37 and 85.
Now mangOH Green comes along and registers 3 GPIO expanders into the kernel. Let’s say that these expanders cover GPIOs 500-547. When the user tries to do echo 501 > /sys/class/gpio/export, the same code as before checks to see if there is an entry for 501 in the mapping table. There is no entry because the mapping is built at kernel compile time and only covers CF3 GPIOs. As a result, the export fails.
Due to this issue, at the time that the mangOH Green was released, we built the GpioExpanderService app which is a Legato app which is essentially a userspace driver for the SX1509 GPIO expander. This allowed users to use the same le_gpio.api interface that they were familiar with from the CF3 GPIOs exposed by Legato to talk to the GPIO expander GPIOs. This works ok, except that it means that the GPIO expander GPIOs can only be accessed from a Legato application. You can’t (for example) easily manipulate a GPIO from the command line or a script. The other problem is that if you wanted to use one of the GPIO expander GPIOs within the kernel, you can’t. This could be the case if the data ready line of a data acquisition device was connected to a GPIO expander GPIO.
MuxControl is an application that binds to GpioExpanderService to provide a high level way of selecting which hardware is active and where it is routed.
The shortcomings of the GPIO mapping table are finally being addressed, but it’s unclear how long it will be until these changes will land in a stable release from the WP product teams.
@dfrey, thank you so much for this explanation very well detailed …
So, we can deduce that the GpioExpander application available here: https://github.com/mangOH/GpioExpander has the same role as the MuxControl application! can you confirm?
MuxControl sits on top of GpioExpander. It provides a clearer interface since the names indicate which function is being controlled whereas just turning on/off a GPIO does not.