[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 14.10.2012 22:12, Uwe Bonnes wrote:
    >>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
    Harald> May be you can, but I have my doubts, that anyone will maintain
    Harald> such a beast or port it easily to a new platform. It will be a
    Harald> PITS, which indeed hurts. ;-)
    >>
    Harald> Ulrich, you are mainly explaining advantages of having an API
    Harald> for GPIO, which I did not put into question. My objection is,
    Harald> that this needs to be done in a portable API, available on all
    Harald> targets.
    >>  Huch, where do we disagree now?
    >> 
    >> Where do you disagree in the used of the Gpio API in owibus_bbif.c?

    Harald> I do not disagree with the implementation of owibus_bbif.c. This
    Harald> driver is designed to run on all platforms that provide Gpio. It
    Harald> must use the portable Gpio API.

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

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

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