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

[oss at c-mauderer.de]

Hello Karel and Duc,

Am 26.06.22 um 09:24 schrieb Duc Doan:
> Hello Karel,
> 
> I came up with this solution: making a macro that returns a function
> depending on driver/BSP name.
> 
> /**
>    * @brief Get an GPIO control object.
>    *
>    * This macro requires BSPs/drivers to correctly implement
>    * function <driver_name>_gpio_get_ctrl(void *arg,
>    * rtems_gpio_ctrl_t **out).
>    *
>    * @param _driver is the name of the BSP/GPIO driver
>    * @param[in] _arg is the void pointer to an argument type
>    *        defined by BSP/driver
>    * @param[out] _out is the pointer to the pointer to where
>    *             the output object will be stored
>    */
> #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.

> 
> What do you think about this?
> 
> Best,
> 
> Duc Doan
> 
> On Sat, 2022-06-25 at 21:46 +0200, Karel Gardas wrote:
>>
>> Hello Duc,
>>
>> one reminder, your API should be more or less portable. That means
>> the
>> example which you produce as a testing example should be API-wise
>> portable between various BSPs. Is that clear?
>>
>> I know, I know, sometimes user led 1 on F4 is on different port/pin
>> on
>> F7 and then on H7 you get it on even different port/pin, but!
>>
>>   > stm32f4_gpio_get_ctrl(GPIOD, &ctrl);
>>
>> do you expect this to be called from app running on RPi4 for example?
>> Or
>> on beagle bone white? Or on stm32h757i-eval board?
>>
>> Please generalize and make that bit portable too.

I think that approach is due to my suggestion to have a low overhead and 
use the pointers more or less directly. A really portable method would 
be to use for example device files. But for GPIO that would add a lot of 
overhead which isn't good for a fast interface like that.

Another problem that I added for Duc is that I told that I might want to 
register I2C GPIO expanders during the application startup.

A possibility could be to have some general bsp_gpio_get_ctrl(...) 
function that returns the controllers for the integrated GPIOs of a chip 
regardless of the chip. If you have an extra I2C expander, that will be 
a separate function.

Best regards

Christian

>>
>> Thanks,
>> Karel
>>
>> On 6/25/22 15:00, Duc Doan wrote:
>>> Hello Christian,
>>>
>>> I forgot to send the sample code. Here it a code to turn on an LED:
>>>
>>> /*****************************************/
>>>
>>> // Obtain the pointer to the instance (port D)
>>> rtems_gpio_ctrl_t *ctrl;
>>> stm32f4_gpio_get_ctrl(GPIOD, &ctrl);
>>>
>>> // enable clocks for port D
>>> rtems_gpio_initialize(ctrl);
>>>
>>> // configure the pin
>>> rtems_gpio_set_pin_mode(ctrl, &LED_PIN,
>>> RTEMS_GPIO_PINMODE_OUTPUT_PP);
>>> rtems_gpio_set_pull(ctrl, &LED_PIN, RTEMS_GPIO_PULLUP);
>>>
>>> // output to LED
>>> rtems_gpio_write(ctrl, &LED_PIN, RTEMS_GPIO_PIN_SET);
>>>
>>> /*****************************************/
>>>
>>> Best,
>>>
>>> Duc Doan
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel