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

[oss at c-mauderer.de]

Hello Duc,

Am 24.06.22 um 16:28 schrieb Duc Doan:
> Hello Christian,
> 
> On Thu, 2022-06-23 at 18:30 +0200, oss at c-mauderer.de wrote:
>> Another tricky part can be how to handle pins or pin groups. At the
>> moment I just used an "unsigned" for a single pin. That wouldn't be
>> able
>> to handle a pin group. Maybe a pin group needs it's own type or some
>> kind of extensible type. For the usual controller with <= 32 bit a
>> mask
>> in a uint32_t would be great. For other controllers maybe a longer
>> mask
>> is necessary. That's a bit tricky.
> 
> Thank you for the pseudocode, I think your method is better than mine.
> I am currently rewriting the code. However, I am not clear about pin
> groups: Is a "pin group" same as a "port"? Or does a group mean pins
> from that group can come from different ports/GPIO controllers?

It's not unlikely that you want to change multiple pins on one 
controller at the same time. That's what I meant with "pin groups". On a 
controller level it would be (for most controllers):

- Read current value from output register into a temporary variable.
- Change the pins in the group to the new value in that temporary variable.
- Write back the new value to the output register.

> 
> Also, I am thinking that maybe I can create an opaque type for pin mask
> that BSPs will implement, instead of a specific type like
> uint32_t. That type could be used as a long mask or just a pin number,
> depending on the BSP.

Be careful with everything that depends on the BSP. Again: Please think 
about an i2c GPIO expander. That chip can be used on different BSPs. It 
can be even an independent driver that can be used by a user on demand 
on any BSP that supports i2c.

Best regards

Christian

> 
> Best,
> 
> Duc Doan
>