[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
bon at elektron.ikp.physik.tu-darmstadt.de
Tue Oct 16 11:19:05 CEST 2012
>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
Ole> Hi Uwe,
>> This sounds good. But what do with platform independant code
>> requesting e.g. pulldown on AVR? Should configure fail or should
>> user code check the actual flags? The AVR can't pulldown at all.
Ole> Yes, I know...
Ole> Even with this little sub-set we will find architectures that do
Ole> not support every setting. For example the LPC, it has some port
Ole> pins that even do not support to set a pin high, as they are only
Ole> open drain.
Ole> But we have to find a compromise:
Ole> My first intention would be:
Ole> Keep it simple. If the CPU does not support pulldown, just ignore
Ole> the flag. Returning an error code would be an option as well but
Ole> would need more code to check this flag.
Ole> In this case I realy vould vote for simplicity. Better document the
Ole> behaviour for different platforms, but do not complicate the code.
>> We also miss MULTIDRIVE here. Without MULTIDRIVE we can't do e.g. a
>> bitbanging TWI driver.
Ole> Why not? There are tons of bitbanging TWI implementations for AVR
Ole> out there...
Ole> You just would have to change pin-configuration from output / low
Ole> to input / pullup. and the other way round to emulate open-drain
Ole> That's why I would not use MULTIDRIVE in a portable bitbanging
Ole> driver but this way of emulation.
>> With MULTIDRIVE we also have a problem with AVR. Let's take this
>> example for AVR:
>> NutGpioPinSet( p, b,.. MULTIDRIVE) NutGpioPinSetLow( p, b);
>> NutGpioPinSetHigh( p, b);
>> This doesn't result in a TRISTATE AVR pin. If we add a explicit
>> function to release and drive a pin, we can handle this for AVR. For
>> most other platforms release() and drive() will be empty macros.
Ole> Exactly. But we can emulate the multidrive behaviour as shown
Ole> above, so why not use the emulation for portable drivers and
Ole> specialization for architecture specific drivers.
I am so fed up by this discussion that I don't see where above you have shown
portable code that can e.g. implement a bitbanging TWI or one-wire
driver. We now have such portable drivers as dev/twibus_gpio.c and
Tell me how you would implement e.g. for dev/owibus_bbif.c the
BB_OwiTransaction() bitbanging as platform independant as it is now with your
proposal that dislike MULTIDRIVE, release() and drive().
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