[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
ulrich.prinz at googlemail.com
Mon Oct 15 20:33:09 CEST 2012
Uwe, I already explained 1000 times that there should never be a
MULTIDRIVE as this implies that you default to PUSHPULL and that will
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.
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
> 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?
More information about the En-Nut-Discussion