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

[Duc Doan]

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