Hello Karel and Christian, I am thinking of this way: referring to a pin using a number. Each BSP will map that pin number to its specific port and pin. For example, for STM32F4 which has 16 pins per GPIO port, pin 6 will correspond to GPIOA pin 6, and pin 20 will correspond to GPIOB pin 4. The get controller function will be as follow:
rtems_gpio_ctrl_t *bsp_gpio_get_ctrl(uint32_t pin); This function must be implemented by each BSP. This will take the pin number and return the corresponding controller object. The example application could be as follow: rtems_gpio_ctrl_t *ctrl0 = bsp_gpio_get_ctrl(60); //corresponds to GPIOD pin 12 on F4 rtems_gpio_write(ctrl, 60, RTEMS_GPIO_PIN_SET); This, however, only returns integrated GPIO from a BSP. In order to use a GPIO expansion, a separate function must be used. Each GPIO expander driver will have its own get_ctrl function. For example, when using 2 different expanders exA and exB: rtems_gpio_ctrl_t *exA_ctrl = exA_get_ctrl(pin); rtems_gpio_ctrl_t *exB_ctrl = exB_get_ctrl(pin); I think this method will assure that it compiles and works on all BSPs but needs an additional function to get the controller of an expander. A drawback might be added computation because of translating abstract pin number to physical pin/port. What do you think about this? Best, Duc Doan On Sun, 2022-06-26 at 20:48 +0200, Karel Gardas wrote: > On 6/26/22 10:49, Duc Doan wrote: > > > > #define rtems_gpio_get_ctrl(_driver, _arg, _out) \ > > > > _driver##_gpio_get_ctrl( _arg , _out ) > > > > > > > > In the application code: > > > > > > > > rtems_gpio_get_ctrl(stm32f4, GPIOD, &led_ctrl); > > > > rtems_gpio_get_ctrl(stm32f4, GPIOA, &button_ctrl); > > > > > > It's only a different method of writing the same. It won't solve > > > Karels > > > problem because it still wouldn't compile on another BSP. > > > > > > > Do you mean this application code should compile on other BSPs > > without > > changing the source? > > Yes, that's exactly what portability means and that's exactly what is > desired outcome of the API here -- if I'm not mistaken in your > project > outcome specification. :-) > > I'm not expert here, so please bear with me, but as I see it, you > will > need to come with some abstraction for groups and pins and write API > around it. Then in BSP you will perform/provide a mapping between > your > abstracted group/pins construct and between actual hardware. This > way, > if I take example from stm32f4 and try to compile on rpi4, it will > compile well -- but it will not run well (probably!) of course. But > API > wise, it will compile. Now, to make it run, I'll need to connect LED > example following BSP specific mapping and for that I need to consult > BSP docs. > > > I am a bit confused about that because I thought > > at least we still need to specify the pin/port. And if we have > > multiple > > GPIO controllers, we still need to select one right? > > Yes, and this needs to be done in abstract manner mapped down into > actual BSP implementation code. Abstract mapping here ensure > portability > between BSPs/boards. > > E.g. for stm32f4 you do not select GPIOA group and pin1, but you > select > group 0 and pin 1 and in f4 BSP this group 0 is mapped to GPIOA and > pin > 1 is mapped to its pin 1. -- something like that. > > Karel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
