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

[Duc Doan]

Hello Christian and Karel,

On Sun, 2022-06-26 at 10:02 +0200, oss at c-mauderer.de wrote:
> 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.
> 

Do you mean this application code should compile on other BSPs without
changing the source? 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? 

Best,

Duc Doan

> > 
> > 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


> >