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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
