Hello,
I would like to know when will be available the GpioExpander (in adition to IoT slot card). I need the GPIO expander in order to activate an user LED to know the status host of the communication established by the IoT board( Renfell RS485)
Best regards
It’s complicated…
The SX1509 GPIO expander is an I2C device attached to the I2C bus of the mangOH Red.
The legato app GpioService provides a Legato API (le_gpio.api) that allows Legato apps to control GPIOs. Internally this is implemented using the sysfs facilities provided by gpiolib in the Linux kernel.
There is a Linux kernel driver that supports the SX1509 so it should be possible to register the SX1509 as a gpiochip into the kernel. There are two main problems with this.
ext_gpio_wp array in drivers/gpio/gpiolib-sysfs.c in the WP76 kernel. There are many problems with this approach, but the one that is relevant here is that this is a compile-time table. So when the SX1509 driver dynamically registers a new gpiochip, there is no entry added into the table. So if you do echo 801 > /sys/class/gpio/export (assuming 801 is a GPIO on the sx1509) you will get an error because there is no entry in the lookup table for 801.I reported this issue a long time ago internally within Sierra Wireless, but so far no work has been done to address this design flaw. I provided a suggestion which was to create functions to register/deregister aliases. So then we could present /sys/class/gpio/aliases/WP_GPIO32 which when read would return “77”.
Because of the issue with using the kernel driver with the Sierra Wireless kernel, we created the GpioExpanderServiceRed app. This app is basically a userspace i2c driver for the sx1509. If you don’t care about controlling the GPIOs from inside the kernel or from the Linux command line, then this approach works fine.
The problem now is that we do care about controlling the GPIOs of the expander from within the kernel. There’s an IoT slot kernel module which needs to manipulate the GPIO expander to provide access to relevant hardware. For example, GPIO expander GPIO 9 controls SDIO_SEL which must be manipulated to provide SDIO access to the IoT slot.
So the sum things up:
Dear David,
Thanks a lot for your reply.
Following your summarise scheme:
If you want the IoT slot driver and control over the GPIO expander from userspace you are out of luck.
It seems MangOH needs some more time to be a completely stable platform…
If you want the IoT slot driver, but no access to the GPIO expander from userspace then you don’t need to do anything. This is the way the mangOH_Red.sdef is setup today.
In my app I can ignore the expansion ports, but then mangOH Red losses the user LEDs if you are using the IoT expansion card. I think this should be becomed aware somewhere in the documentation (or more clearly)
If you don’t need the IoT slot driver, but want access to the GPIO expander from userspace, then you need to comment out the code in the mangoh red kernel module which instantiates the sx1509 device, the iot slot device and the mux functionality that is passed to the iot slot device.
I tried to do that, uncomment the line $MANGOH_ROOT/apps/GpioExpander/gpioExpanderService/gpioExpanderServiceRed, and comment all the lines referenced to the IoT slot, but the application view (I´m using DEVSTUDIO) reports me a binding problem when I run the app…
best regards
Hello Ivand,
I think David was talking about Kernel not gpioExpanderService app for the latest point.
Regards,
This is sort of a mangOH issue. The mangOH team works on items related to hardware on the mangOH board, but outside of the WP module. It’s really more of an issue for the team that builds the Linux that runs on the WP since the gpiolib component has been modified in a way that is hostile to the possibility of gpiochips from outside of the WP module.
What is the binding problem that is being reported? I’m not a developer studio user, so I’m not too familiar with the exact details of what you’re seeing.
Hello David,
thanks for your reply.
DEV STUDIO compile fine, but when your are running the app (timerLED) the device status reports binding problems with the GPIO used:
I don´t have experience developing in DEV STUDIO , but for me is better than CLI on Linux because I don´t know Linux very much, so I can not give you more information about the problem.
Maybe, that is my problem with mangOH, it seems you can power on the module and quickly develop a cloud application learning legato, but at this moment, my personal opinion is that you need to have a strong foundations on Linux in order to successful preparing of mangOH device.
Can you share your adef ?
Dear asyal,
this is the .adef. I try to blink LED410 and I get the binding problem:
sandboxed: true
version: 1.0.0
maxFileSystemBytes: 512K
start: manual
executables:
{
timerLed = ( timerLedComponent )
}
processes:
{
envVars:
{
LE_LOG_LEVEL = DEBUG
}
run:
{
( timerLed )
}
faultAction: restart
}
bindings:
{
timerLed.timerLedComponent.mangoh_ledGpio -> le_gpio.le_gpioPin34
}
I really appreciate your help.
Best regards
Are you using WP76 or WP85?
This wont work on WP76 but if yiu are using WP85, see if the following work:
le_gpio.le_gpioPin34 should be .le_gpioPin34 or gpioService.le_gpioPin34
I´m using WP85xx
Thanks for your reply.
I just try your comment, and it keeps having a missing binding warning, and the LED doesn´t blink.
Are there any way to know if the resource GPIO34 is already in use by other app?? or could I share this resource from different apps??
Best regards
I´ve been looking for info in web and sending AT+WIOCFG? the system reply with:
34,0,0,0,10,0.
Configuring the #34 to 34,16,0,0,1,0,0 it still not working.
More info: Using GPIO2 instead of GPIO34 works fine.
What could be wrong with #34 ?
Can you tell me what version of mangoh red are you using? The commercially launched version will show Rev 5 back on the back of the pcb. Also can you show what led are you looking at?
Hi Asyal,
I´m using MangOH Red REV5.0. The LED I´m looking for is D410 (see de attached image).
Best regards
Hi!
Make sure you have set the:
at+wiocfg=34,16,0,0,1,0,0
and power cycle the Red board.
Than try, that the LED work from the CLI:
echo 34 > /sys/class/gpio/export
cd /sys/class/gpio/gpio34
echo out > direction
echo 1 > value # … LED ON
echo 0 > value # … LED OFF
Hi!!
Thanks!!! now is working!!
is there any
possibility to configure this option from code?, or is strictly
necessary run AT commands??
Best
regards
You can send AT commands from code: http://legato.io/legato-docs/latest/c_atClient.html
I’m not aware of a method that doesn’t use AT commands.
Hi guys,
A little late to the party, but I’m trying to get GPIO34 to work as well. I’ve tried using the at command to ensure the linux host has access to the pin, however the module doesn’t seem to accept the command.
When I enter “AT+WIOCFG=34,16,0,0,1,0,0” I only get the response “ERROR”. Other commands (read/write) to that pin also return error.
Interestingly, when I list all the GPIO configurations I’ve noted that 34 is not listed:
+WIOCFG: 2,16,0,0,1,0,0
+WIOCFG: 6,0,0,0,1,0,0
+WIOCFG: 7,16,0,0,1,0,0
+WIOCFG: 8,16,0,0,1,0,0
+WIOCFG: 13,16,0,0,1,0,0
+WIOCFG: 21,16,0,0,1,0,0
+WIOCFG: 22,16,0,0,1,0,0
+WIOCFG: 23,16,0,0,1,0,0
+WIOCFG: 24,16,0,0,1,0,0
+WIOCFG: 25,16,0,0,1,0,0
+WIOCFG: 28,16,0,0,1,0,0
+WIOCFG: 29,16,0,0,1,0,0
+WIOCFG: 30,16,0,0,1,0,0
+WIOCFG: 31,16,0,0,1,0,0
+WIOCFG: 32,16,0,0,1,0,0
+WIOCFG: 33,16,0,0,1,0,0
+WIOCFG: 35,16,0,0,1,0,0
+WIOCFG: 42,16,0,0,1,0,0
How do I go about fixing this?
Thanks
what module are you using?
Hello asyal,
After posting this I reviewed the mangoh red schematics and the WP7702 pinout. I realized that pin 100 of the module was not made available. So I’m unable to use that pin.
Thank you for the reply!