On Tue, Jul 11, 2023 at 7:05 AM Christian MAUDERER <christian.maude...@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. > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel