[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
harald.kipp at egnite.de
Mon Oct 15 15:46:29 CEST 2012
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.
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.
More information about the En-Nut-Discussion