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

Harald Kipp harald.kipp at egnite.de
Mon Oct 15 18:29:56 CEST 2012

Hi Uwe,

On 15.10.2012 17:55, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>     Harald> Some chips seem to provide specific dedicated pin set/clear
>     Harald> registers.  Here we could use
>     GPIOB-> BRR = (1 << I2CBUS1_SDA_PIN);
>     Harald> I understood, that other STMs are different
> No, all STM32 I know have Bit_set and Bit_clear register. STM32 ports are 16
> bit wide. Both registers are stacked together as as 32 bit register, with
> set the lower 16 and reset the upper 16 bits.
> Some families also expose the reset register additional as the lower 16 bit
> of a 4 byte aligned other 16-bit register

I understand, thanks for clarification.

>     Harald> These statements take a single instruction only, same as bit
>     Harald> banding.  The advantage is, that it is faster than bit banding,
>     Harald> because there is just a write cycle required. GpioPinSetLow
>     Harald> needs an additional read cycle.
> Why do you think that GpioPinSetLow takes an additional read cycle? With
> Bit0 '0' writen to the Bitbanding address the bit is reset, with '1' ist is
> set.

Oh, I thought that the CPU first reads the peripheral register, then
modifies it, and then writes it back to the peripheral register. May be
I should read more about how Cortex-M works internally. Sorry for the

> But here we are at the internal implementation of GPIO for the STM32
> platform. Isn't that independant of the Ethernut GPIO Api? Do yu care if
> setting a pin in the bitbanging drivers is a tick slower on one platform
> then it could be hand-coded in a non-portable way?

No, I don't care. I was just in doubt, that GpioPinSetLow can do it in
the optimal way on all platforms, as you claimed in


 "that the GPIO API is as fast as unportable code"

So I was under the wrong impression, that I found such a case. I'm sure
there are others.

Anyway, you asked me

>     Uwe> Huch, what should I do else? Write
>     Uwe> "CM3BBREG(I2C_PORT, GPIO_Typedef, BSRR,
>     Uwe> 1<<(I2CBUS1_SDA_PIN+16))"
>     Uwe> instead of "GpioPinSetLow( I2C_PORT, I2CBUS1_SDA_PIN)"?
>     Uwe> GpioPinSetLow
>     Uwe> resolves to the code above.

so that was the answer to this question.

>     Harald> Sorry, that was a serious question, not a didactic question. I'm
>     Harald> just curious, if you intend to implement GPIO_PinAFConfig
>     Harald> features into GpioPinConfigSet to make it more portable.
> Ulrich's proposal intended to do so. The STM32 gpio usage doesn't do that at
> the moment, neither does LPC. avr32/dev/pwm.c puts the argument for the pin
> configuration in the flags, that's the only file i see such a use.
> I can do so for STM32 too, I am totally unbiased in that regard.



More information about the En-Nut-Discussion mailing list