[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status

[Harald Kipp]

Hi Uwe,

On 15.10.2012 10:53, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

>     Harald> I disagree, for example, with
>     Harald> arch\cm3\dev\stm\stm32_twi1.c. This is STM32 specific code and
>     Harald> don't need to use the portable Gpio API.
> 
> Huch, what should I do else? Write
> "CM3BBREG(I2C_PORT, GPIO_Typedef, BSRR, 1<<(I2CBUS1_SDA_PIN+16))"
> instead of "GpioPinSetLow( I2C_PORT, I2CBUS1_SDA_PIN)"? GpioPinSetLow
> resolves to the code above. 

That's a little bit unfair ;-). I do know almost nothing about STM32 and
CM3. Anyway, I'll try, sorry if I missed something.

Some chips seem to provide specific dedicated pin set/clear registers.
Here we could use

 GPIOB->BRR = (1 << I2CBUS1_SDA_PIN);

I understood, that other STMs are different

 GPIOB->BSRRL = I2CBUS1_SDA_PIN;

These statements take a single instruction only, same as bit banding.
The advantage is, that it is faster than bit banding, because there is
just a write cycle required. GpioPinSetLow needs an additional read cycle.

Again, correct me, if I'm wrong. I'm not familiar with this hardware,
but you may get the idea.

For other registers you may need bit banding. Then it is probably
possible to create a less complicated macro and use it like

 BB_PERIPH(&GPIOB->ODR, I2CBUS1_SDA_PIN) = 1;

which is easier to read than the swiss army knife version

 CM3BBREG(I2C_PORT, GPIO_Typedef, BSRR, 1<<(I2CBUS1_SDA_PIN+16));


> 
>     Harald> Several STM32 drivers extend the API with GPIO_PinAFConfig. Do
>     Harald> you intend to integrate this into GpioPinConfigSet?
> 
> The Pin needs configuration of the alternate mode. So again, how do you
> propose to write that code?

Sorry, that was a serious question, not a didactic question. I'm just
curious, if you intend to implement GPIO_PinAFConfig features into
GpioPinConfigSet to make it more portable.

Regards,

Harald

P.S. Just to make this clear: I'm not promoting C structures for
peripherals in opposite to inline functions. I just adapt my samples to
the current status quo. But that's a different topic, which I already
stressed a lot in the past.