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