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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
