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

Mon Jun 27 06:29:11 UTC 2022

Hello Duc,

Am 27.06.22 um 05:34 schrieb Duc Doan:
> Hello Karel and Christian,
> 
> I am thinking of this way: referring to a pin using a number. Each BSP
> will map that pin number to its specific port and pin. For example, for
> STM32F4 which has 16 pins per GPIO port, pin 6 will correspond to GPIOA
> pin 6, and pin 20 will correspond to GPIOB pin 4. The get controller
> function will be as follow:

That numbering scheme is used by for example Linux. Seems to work for 
them as an universal one so I don't think that we should get problems.

Please think about whether you want to start at 0 or at 1!

> 
> rtems_gpio_ctrl_t *bsp_gpio_get_ctrl(uint32_t pin);
> 
> This function must be implemented by each BSP. This will take the pin
> number and return the corresponding controller object. The example
> application could be as follow:
> 
> rtems_gpio_ctrl_t *ctrl0 = bsp_gpio_get_ctrl(60); //corresponds to
> GPIOD pin 12 on F4
> 
> rtems_gpio_write(ctrl, 60, RTEMS_GPIO_PIN_SET);

Be really careful with that syntax. If you use increasing numbers like 
you suggested, every controller would have to know it's own offest. On 
the other hand, if there is a unique number to each pin, you don't 
necessarily need the "ctrl" pointer at all. You can just use something like

    rtems_gpio_write(60, RTEMS_GPIO_PIN_SET);

That's an advantage from the usage perspective because you don't have to 
fetch the GPIO controller and can work with a single pin number.

Disadvantage is a overhead in the API: You have to create some global 
table with GPIO controllers and their first and last pins. That table 
has to be searched for every operation. In the worst case it adds a loop 
over the table with one comparison for each entry. Most systems should 
only have a hand full of GPIO controller so it's not too much but it's a 
lot more than just one pointer de-referencing. There could be methods to 
optimize the search so the loop might isn't the best solution. But every 
search is slower than if you already have the pointer.

It's more or less a trade-off. There are good arguments for both 
directions. I think I have seen both directions implemented in different 
situations.

> 
> This, however, only returns integrated GPIO from a BSP. In order to use
> a GPIO expansion, a separate function must be used. Each GPIO expander
> driver will have its own get_ctrl function. For example, when using 2
> different expanders exA and exB:
> 
> rtems_gpio_ctrl_t *exA_ctrl = exA_get_ctrl(pin);
> rtems_gpio_ctrl_t *exB_ctrl = exB_get_ctrl(pin);

What would be the pin numbers in that case? You mentioned that the 
STM32F4 has 16 pins per GPIO. Let's assume it's 4 GPIOs so the last 
internal GPIO would be 16*4-1=63. Would the first registered expander 
have pin numbers starting at 64 or again at 0?

I would strongly suggest to use the same method for internal and 
external GPIOs. If you start with 0 for an expander, start with 0 for 
each internal GPIO controller too (in the STM example: You should have 4 
internal pins with the number 0). If you plan to have an increasing 
number, use that for the external GPIO controllers too.

Best regards

Christian

> 
> I think this method will assure that it compiles and works on all BSPs
> but needs an additional function to get the controller of an expander.
> A drawback might be added computation because of translating abstract
> pin number to physical pin/port.
> 
> What do you think about this?
> 
> Best,
> 
> Duc Doan
> 
> On Sun, 2022-06-26 at 20:48 +0200, Karel Gardas wrote:
>> 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/