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

[Uwe Bonnes]

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

    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
owibus_bbif.c.

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().

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

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