[PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

[Karel Gardas]

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