Need community suggestions for a new generic GPIO API

[Christian MAUDERER]

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.

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/