Hello Christian and Karel, On Sun, 2022-06-26 at 10:02 +0200, o...@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 > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel