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

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

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

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

    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

    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.

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?

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

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

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

    Harald> which is easier to read than the swiss army knife version

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

We can argue about the Macros I introduced, the names are sub-otipmal. But
still I don't see the advantage of writing "BB_PERIPH(&GPIOB->ODR,
I2CBUS1_SDA_PIN) = 1;" or something similar against GpioPinSetLow(port, pin). 

    >>
    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?

    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.

But if we ever see the alternate function setting in platform independant
code, there is something wrong.

So again, putting GPIO_PinAFConfig is internal platform implementation and
other platforms and NUT/OS itself have very few reasons to care how it is
done internal... 

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------