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

[Ulrich Prinz]

Ouch...

Uwe, I already explained 1000 times that there should never be a 
MULTIDRIVE as this implies that you default to PUSHPULL and that will 
kill hardware.

If you are a newbie that tries the first steps you probably set just the 
PINCFG_OUTPUT option. That could kill pins on the lines that are either 
intended for open-collector only or are erroneously configured as 
outputs on the other end.

So without user-intervention a pin should never be configured as 
push-pull. So MULTIDRIVE is obsolete.
On AVR you just use _OUTPUT or _OUTPUT | _PULLUP.
On ARM you can use the same if provided or _OUTPUT | _PULLUP10k or 
whatever the chip likes to have.

Ulrich

Am 15.10.2012 18:18, schrieb Uwe Bonnes:
>>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
>
>
>      Ole> - Simple GPIO API with: - configure input / output, pullup,
>      Ole> pulldown, set pin value, get pin value, set pin high, set pin low
>
> 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.
>
> We also miss MULTIDRIVE here. Without MULTIDRIVE we can't do e.g. a bitbanging
> TWI driver.
>
> 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.
>
> The commands should also have a portwide counterpart with a mask argument. If
> a platform in the sense of a 48-pin STM32 without FSCM (*1) versus a 144 pin
> STM32 with FSCM has no businterface, we need to be able to implement a
> bitbanging bus interface. And we shouldn't ripple through the related pins.
>
>   (*1)Flexible static memory controller (FSMC)
>
>      Ole> - Drivers: Try _not_ to use the I/O api as long as it is not a
>      Ole>   - Try to keep functions as short as possible, try to be atomic
>
>      Ole> - CPU specific API for more detailed pin configuration Even double
>      Ole> code would be ok, if we keep things more clear then.
>
>      Ole> - Sample programs:
>
>      Ole>   - Try to keep samples simple, always try to initialize I/Os in
>      Ole> the board file, do not create common samples that need more
>      Ole> sophisticate I/O pin settings.
>
> Here again we need to think about a use case that is probably not thought of
> yet. Someone has e.g. an Embed board, puts it in a breadboard and connects
> e.g. a TWI portextender with flying wires. Then the user should have an easy
> way to configure his setup,  at least without going through the configurator.
>
>      Ole> bitbanging driver. Bitbanging drivers should try to use only common
>      Ole> API functions.
>
> Huch: So you consider the code in e.g. arch/cm3/dev/nxp/lpc177x_8x_mci.c:
>     // Force all MCI control pins to basic I/O mode
>      GpioPinConfigSet(NUTGPIO_PORT0, 19, GPIO_CFG_OUTPUT);      // SD_CLK
>      GpioPinConfigSet(NUTGPIO_PORT0, 20, GPIO_CFG_OUTPUT);      // SD_CMD
>      GpioPinConfigSet(NUTGPIO_PORT1, 5, GPIO_CFG_OUTPUT);       // SD_PWR
>
> not good?
>
> Bye
>