[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
bon at elektron.ikp.physik.tu-darmstadt.de
Mon Oct 15 10:53:15 CEST 2012
>>>>> "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
>> 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?
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the En-Nut-Discussion