[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> - 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
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

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