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 <math...@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&data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aXf1bfSt6gOytbBEli5sc2ZYw4Jga3Woh0PVP%2BfMZQw%3D&reserved=0
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnuttx%2Fincubator-nuttx%2Fblob%2Fef87a8c70363d6cc3bc4247de0dc153a6f9b6d27%2Fdrivers%2Fioexpander%2Fgpio.c%23L333&data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kkzlGg%2FMMk3Jun6VLVFS6qhrwRd%2FV%2Bz9NiFxiGr08Fw%3D&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&data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=G3Bztg81uTME%2B8J7bkV0IDbX9%2F0IxuhhOmZamJmr6sI%3D&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&data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W7CKL0XEhn9YTbskfYwTT8svYNLglWc%2B8gdc8faloEw%3D&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&data=04%7C01%7Cjari.vanewijk%40nxp.com%7Cad403e7160fd41834ed808d99a3849bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637710388814641538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FZ9GcnZGNN58iNSk6cyEYnwRHdiB5Y4Fkr6BDmFlx78%3D&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 <jari.vanew...@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
>>
