[En-Nut-Discussion] Unified GPIO implementation

[Harald Kipp]

On 06.10.2010 07:29, Thiago A. Corrêa wrote:
> they are 8 bit or 32 bits. It's suggested:
> 
> AVR:
> int8_t GpioPinConfigSet( uint8_t port, uint8_t pin, uint8_t cfg)
> 
> AVR32,ARM,Cortex
> int GpioPinConfigSet( uint32_t port, uint32_t pin, uint32_t cfg)
> 
>     Why not define it as simply int8_t GpioPinConfigSet( uint8_t port,
> uint8_t pin, uint8_t cfg) for all architectures?

The compiler will generate additional code for 32-bitters with uint8_t
arguments to clear the upper bytes of the register. I'd recommend to use
uint_fast8_t. See

http://en.wikipedia.org/wiki/Stdint

But the return value caught my attention:

int8_t function();

IMHO won't help 8-bitters. AFAIK, functions always must return at least
2 bytes on the AVR. Simply because C allows to call unknown functions.
Such functions are expected to return an integer value.


> We already have those defined in include/dev/gpio.h, except that _PORT
> is 0 and _PORTA is 1. Should we change it?

My initial intention was, to have distinct definitions for the users of
single port CPUs like the AT91R40008. Later I recognized, that

#define xxx_PORT xxx_PORTA

would have been sufficient. We really do not need to distinguish PORT
from PORTA in the API. I have no objections to change this.


> There is also one area that is not covered in the document. The
> AVR32 toolchain defines which references the GPIO set their values as
> pin numbers, not ports/pins. So, some sort of conversion macro is
> needed, to use that convention with the port/pin convention in Nut/OS.

I think Michael Fischer already implemented such a macro. In general it
is not a bad idea to use pin numbers only. It would save one parameter
in the function call.

Regards,

Harald