Mangoh Red GPIOExpander


#1

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


#2

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.

  1. The Legato GpioService has a static list of GPIOs that it supports. So if we dynamically add more, they don’t automatically become supported by the GpioService. This could probably be worked around by having a MangohRedGpioService that re-uses some of the components of GpioService.
  2. Sierra Wireless made modifications to gpiolib in the Linux kernel. The idea was to provide an abstraction between the GPIO numbers that users are familiar with based on the labels of the WP module pins and the internal GPIO numbers. For example, on the WP76 the pin labeled “GPIO32” in the WP schematic is actually GPIO 77 inside the Linux kernel. This mapping table is represented in the 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:

  • If you want the IoT slot driver and control over the GPIO expander from userspace you are out of luck.
  • 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.
  • 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.

#3

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


#4

Hello Ivand,

I think David was talking about Kernel not gpioExpanderService app for the latest point.

Regards,


#5

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.


#6

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:
image

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.


#7

Can you share your adef ?


#8

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


#9

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


#10

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


#11

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.


#12

More info: Using GPIO2 instead of GPIO34 works fine.

What could be wrong with #34 ?


#13

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?


#14

Hi Asyal,

I´m using MangOH Red REV5.0. The LED I´m looking for is D410 (see de attached image).

Best regards


#15

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


#16

Hi!!

Thanks!!! now is working!!

is there any
possibility to configure this option from code?, or is strictly
necessary run AT commands??

Best
regards


#17

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.