[En-Nut-Discussion] Unified GPIO implementation

[Ulrich Prinz]

Hi!

Am 06.10.2010 11:35, schrieb 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
>
that's correct for ARM, but not in all cases for Cortex. But for easy 
code reading, portability and others I could agree to either 
uint_fast8_t or uint16_t.

> 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.
>
The return value could be, but the parameters are actually 32bit for the 
config option. And it should help 8 bit architectures to handle only 8 
bit parameters. And 8bit is far enough to handle the 3..5 options this 8 
bit chips support on their ports.
>
>> 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.
>
Yes, that's what I did for STM to be example-compatible.
>
>> 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.
>
I don't know about AVR32 but with ARM/Cortex it would produce overhead 
as you have to recalculate from pin number back to address of port.
That produces much more overhead than to pass over a second parameter.

I would like to remind that we have two entry ways into Nut/OS:
1) High portability
2) High optimization

1) Is for people that like to start fast into the controller world and 
use our example code. People that try to understand.
It is for people who like to contribute in general and like to write 
drivers apart from the architecture ( that what goes into nut/dev).

2) Is for power users that optimize to the last bit. Code often needs 
high efficiency tweaks that no one else needs to understand if the 
product is into production. And it is for us low-level driver 
programmers that don't accept an LCD that get 100 pixel per second if 
using gpio functions instead of 5Mega-pixel/s if using optimized GPIO 
with SPI and DMA.

I will add my proposals now for GPIO into the Wiki and now with respect 
for AVR32.

Best regards
Ulrich