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

[Harald Kipp]

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
> 
>     GPIOB-> BSRRL = I2CBUS1_SDA_PIN;
> 
> 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
confusion.


> 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

http://lists.egnite.de/pipermail/en-nut-discussion/2012-October/014075.html

 "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.

Thanks,

Harald