On Tue, Jul 11, 2023 at 12:50 PM Gedare Bloom <ged...@rtems.org> wrote:
> 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. > 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@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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
