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

[Ole Reinhardt]

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.

Yes, I know... 

Even with this little sub-set we will find architectures that do not
support every setting. For example the LPC, it has some port pins that
even do not support to set a pin high, as they are only open drain.

But we have to find a compromise:

My first intention would be:

Keep it simple. If the CPU does not support pulldown, just ignore the
flag. Returning an error code would be an option as well but would need
more code to check this flag.

In this case I realy vould vote for simplicity. Better document the
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.

Why not? There are tons of bitbanging TWI implementations for AVR out
there...

You just would have to change pin-configuration from output / low to
input / pullup. and the other way round to emulate open-drain outputs.

That's why I would not use MULTIDRIVE in a portable bitbanging 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.

Exactly. But we can emulate the multidrive behaviour as shown above, so
why not use the emulation for portable drivers and specialization for
architecture specific drivers. 

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

You are right, but this is also a case for a plaform specific driver, is
it? 

Why not implement a platform specific ior(address) and iow(address,
data) function and assign them as low level interface function to the
driver (e.g. by registering them anywhere to the device struct)

This way you could even write drivers that can be used using bitbanging
I/O _AND_ external network interface.

>  (*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

Ok, let's add some device to the io-expander, e.g. an led. Ideally this
would be done by the following pseudo pseudo code:

register_device(twi_port);

twi_register_device(twi_port, ioexpander);

ioexpander_port_nr= gpio_api_add_device(ioexpander, 16bit)


struct led_platform_data led_pdata;

led_pdata = {
	port : ioexpander_port_nr;
	pin  : 10;
}

platform_register_device(dev_led, led_pdata);



I don't know if my idea is clear. In doubt, just ask.


>     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

Yes, i just removed this in r4755 (commented out).

I will remove the comments there in the next step as soon as we agreed
on a common way of configuration.

> not good?

The main problem with configuring the pins in the driver is it's
inflexebility when the peripheral can be mapped to different I/O pins.

Bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280