Re: ioexpander/gpio driver device names

[Jari van Ewijk <ja...@nxp.com>]

Hi Alan, Matheus,

Thanks for your input. I already started working on some changes for the existing interface and driver. It is actually not too much work to adapt the high-level driver to only register pins as /dev/gpioN, and even the low-level drivers for many boards don't require (m)any changes to keep them working with their current feature set. I will probably open a (draft) PR later today or sometime this week, then we can continue the discussion there.

Matheus, your work looks promising. I personally prefer to register only single pins, because then you have more control over what pins can be accessed from an application, instead of "exposing" them all. But I can imagine that it is very convenient to have complete GPIO banks accessible on development boards with large I/O headers. I think it would be a nice addition. I suggest we first try to simplify and improve the existing interface/driver for single GPIO pins and then after that we consider how we can add your proposed extension for complete GPIO banks as well?

Best regards,
Jari


-----Original Message-----
From: Matheus Castello <ma...@castello.eng.br> 
Sent: Thursday, October 28, 2021 7:28 PM
To: dev@nuttx.apache.org
Subject: [EXT] Re: ioexpander/gpio driver device names

Caution: EXT Email

Hi Jari and Alan,

I have a proof of concept of how a "more generic" way of using GPIOs could work, actually running on my port of .NET nanoFramework for NuttX.
The idea is to have an entry per GPIO bank at `/dev/gpio{bank}`, so all the pins of the bank would be managed by this entry.

NuttX side:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fincubator-nuttx%2Fblob%2Fef87a8c70363d6cc3bc4247de0dc153a6f9b6d27%2Finclude%2Fnuttx%2Fioexpander%2Fgpio.h%23L134&amp;data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aXf1bfSt6gOytbBEli5sc2ZYw4Jga3Woh0PVP%2BfMZQw%3D&amp;reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fincubator-nuttx%2Fblob%2Fef87a8c70363d6cc3bc4247de0dc153a6f9b6d27%2Fdrivers%2Fioexpander%2Fgpio.c%23L333&amp;data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=kkzlGg%2FMMk3Jun6VLVFS6qhrwRd%2FV%2Bz9NiFxiGr08Fw%3D&amp;reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fincubator-nuttx%2Fblob%2Fef87a8c70363d6cc3bc4247de0dc153a6f9b6d27%2Fboards%2Farm%2Frp2040%2Fraspberrypi-pico%2Fsrc%2Frp2040_gpio.c%23L189&amp;data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=G3Bztg81uTME%2B8J7bkV0IDbX9%2F0IxuhhOmZamJmr6sI%3D&amp;reserved=0

Application side:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fnf-Community-Targets%2Fblob%2Flinux%2Fposix%2Ftarget%2FPAL%2FCPU_Gpio_Nuttx.cpp&amp;data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=W7CKL0XEhn9YTbskfYwTT8svYNLglWc%2B8gdc8faloEw%3D&amp;reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fincubator-nuttx-apps%2Fblob%2Fdotnet%2Fexamples%2Fgpio%2Fgpio_main.c&amp;data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FZ9GcnZGNN58iNSk6cyEYnwRHdiB5Y4Fkr6BDmFlx78%3D&amp;reserved=0

Remembering that this is an idea, proof of concept, still work in progress.

BR,
Matheus Castello

Em 10/27/2021 4:11 PM, Alan Carvalho de Assis escreveu:
> Hi Jari,
>
> I agree! Also in the Linux its name is just gpioN inside /sys.
>
> But this modification will involve many boards modifications and also 
> the error message will need to give more details explaining that the 
> user cannot use that pin as input because it is configured to output 
> and vice-versa. Also an input without interruption support needs to be 
> handled correctly case someone try to wait for a signal event on the 
> gpio.
>
> BR,
>
> Alan
>
> On 10/27/21, Jari van Ewijk <ja...@nxp.com> wrote:
>> Hi all,
>>
>> I am currently working with the ioexpander/gpio driver to control 
>> GPIO pins from an application. I am wondering if anybody is using 
>> this interface for more practical applications than toggling a pin from the command line (i.e.
>> apps/examples/gpio).
>> I would say the interface is simple but effective. It can read and 
>> set pin values and pintypes can be changed. That's all I need.
>>
>> However, I am wondering about the naming of the devices. Pins are 
>> registered as /dev/gpinN, /dev/gpoutN, or /dev/gpintN (where N is a 
>> integer number, of
>> course) depending on their pintype.
>> Now, there is a SETPINTYPE command, which you can use to change 
>> pintypes. So that means an output pin initially registered as 
>> /dev/gpout0 could be changed to be an input pin, with it keeping the same name.
>>
>> Wouldn't it make more sense to register ALL pins as generic 
>> /dev/gpioN instead of the specific /dev/gpinN, /dev/gpoutN, 
>> /dev/gpintN? Maybe there's a good reason to keep these distinct 
>> names, but it is also really confusing when pin types start to change.
>>
>> Best regards,
>> Jari van Ewijk
>>