Need community suggestions for a new generic GPIO API

Wed Jul 12 12:49:37 UTC 2023

On Tue, Jul 11, 2023 at 12:50 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Tue, Jul 11, 2023 at 7:05 AM Christian MAUDERER
> <christian.mauderer at embedded-brains.de> wrote:
> >
> > Hello Utkarsh,
> >
> > please be a bit careful with GPIO and pin functions. That's a quite
> > difficult topic.
> >
> > Some controller manufacturers mix these functions. One such example is
> > the STM32 family. I'll take the STM32F410 as an example. That chip has a
> > GPIO register block with one GPIOx_MODER where you can select whether a
> > pin is a Input, GPIO, alternate function or analog mode. There is also a
> > GPIOx_OSPEEDR that defines speed and some others that define pull ups /
> > downs and so on.
> >
> > Other controllers - like a lot of the NXP ones - have two completely
> > independent modules for that. I'll take the i.MXRT1050 series as an
> > example: That chip has an IOMUXC where you can set a pin function for a
> > pad. For example, there is a register IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_26.
> > In that register, you can set a pin function of GPIO4_IO26. There is a
> > related PAD_CTL register in the IOMUXC where you can set up pull ups /
> > downs, drive strength and so on. The GPIO controller where you set up
> > levels and interrupts for that pin is a completely unrelated module. On
> > the i.MXRT1166 you can even assign some pins to two different GPIO
> > controllers. So it's not possible to have a 1:1 mapping between pin and
> > GPIO.
> >
> > If you ask me GPIO and pin function are two separate things and need two
> > APIs. That should make it possible to support controllers like the STM32
> > (where some of the GPIO registers would be controlled by the GPIO API
> > and some by the pin function API) and for controllers like the i.MXRT
> > where the two APIs would handle different hardware modules.
> >
> > If you take a look at Linux or FreeBSD, they usually split that up just
> > like that. If you want to dig deeper into that, maybe it would be worth
> > to take a look at some other embedded operating systems. For example
> > Zephyr or Contiki or any of the ones in Wikipedia "Comparison of
> > real-time operating systems". It can even be a good idea to create a
> > compatible interface.
> >
> This reminds me that I think the pinmux was lifted out of libbsd and
> put into RTEMS for the BBB.
> * shared/freebsd/sys/arm/ti/ti_pinmux.c
>
> This may be the right direction to go for other targets, where they
> have support in FreeBSD. And where they don't, compliance to that
> pinmux API may be preferable.
>

Not directly an API but the Virtio standard includes a GPIO device.
Assuming it was well thought out (I would assume it is), that is probably
the easiest device you want this API to interface with.

https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html

FWIW I would like to see RTEMS support the full complement of virtio
device drivers.This should make it easiest to have RTEMS as a guest
under a variety of hypervisors, etc. including Xen.

--joel

>
> > Best regards
> >
> > Christian
> >
> > On 2023-07-07 21:48, Utkarsh Verma wrote:
> > > Dear all,
> > >
> > > While working on the Raspberry Pi 4 BSP, I realized that the GPIO API
> > > could be improved. It seems that last year, a GSoC student worked on
> > > introducing a new GPIO API, called GPIO2 to RTEMS. However, it did not
> > > get merged. Discussing this topic with my mentor and on RTEMS Discord
> > > revealed that it would be a good idea to get it merged. For that, I
> > > would like to ask the community the following:
> > >
> > > - Moving forward, will GPIO2 API be the community-preferred GPIO API?
> > > - What would be the recommended way in this new API to select
> > > alternate pin functions? Will that be left for the BSP to decide?
> > >
> > > Here are the links associated with GPIO2:
> > > Git Repo: https://github.com/dtbpkmte/GSoC-2022-RTEMS
> > > GPIO2 commit:
> https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c
> > > Blog post about the API:
> > >
> https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458
> > > _______________________________________________
> > > devel mailing list
> > > devel at rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> >
> > --
> > --------------------------------------------
> > embedded brains GmbH & Co. KG
> > Herr Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email:  christian.mauderer at embedded-brains.de
> > phone:  +49-89-18 94 741 - 18
> > mobile: +49-176-152 206 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRA 117265
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230712/f277830b/attachment.htm>