[En-Nut-Discussion] Unified GPIO implementation

[Harald Kipp]

On 06.10.2010 20:45, Thiago A. Corrêa wrote:

>> 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
> 
> Ah, ok.
> 
> We already define ureg_t in sys/types.h, it fits perfectly for this:

uint_fast8_t is ANSI standard, ureg_t is a Nut/OS invention. We should
stick with the standard and replace ureg_t with stdint types. The
resulting code is the same.

Furthermore uint_fastN_t types are more portable. They clearly specify
the range of the value.


>> 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.
> 
> For AVR32 it makes sense to use a return type that is the same size of
> the register, as it's usually stored in R12.
> Or it could simply return void.

For CPUs with a register size of 16 bits and above, there is no doubt.
The standard demands, that an int has to be at least 16 bits in size and
any non-void function is expected to return at least the size of an int.
Declaring a global function's return values of less than 16 bit may make
sense, but it will not reduce the code size. Code size may increase.

Note, that this applies to pure global functions only. Inlined or static
function may benefit from 8-bit return values, if used on an 8-bit CPU.


>> would have been sufficient. We really do not need to distinguish PORT
>> from PORTA in the API. I have no objections to change this.
>>
> 
> Ok, can we change this in trunk already then?

Yes, _BUT_ a simply replace may not work. I'm almost sure, that the code
needs to checked as well. Applications shouldn't suffer, though.


> I think we discussed that a while ago and decided to go with the
> Port/Pin pair. Really it doesn't make too much of a difference, but
> for avr 8 bit it might confuse the users who is acostumed with
> ports/pins.

I suggest to implement new functions with pin argument only and redefine
the existing ones by wrapper macros.

This way the AVR programmer still feels comfortable and the
pre-processor will convert the port/pin-pair to a single function
argument, which reduces the code size.


> in the Nutconf. Should we just define a new set of macros for the
> config? Something along the lines of:
> 
> #define ALTERNATE_PIN1  1
> ...
> #define ALTERNATE_PINn  n
> 
> Or perhaps I'm missing an alternative? What do you think?

I'm  still not familiar enough with AVR32 to comment on this one. You're
one of the experts.

Regards,

Harald