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

[Ulrich Prinz]

Hi!

Am 14.10.2012 18:05, schrieb Thiago A. Corrêa:
> Hi,
>
> On Sun, Oct 14, 2012 at 8:50 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
>>
>> And this is the point where I'm still missing an answer:
>>
>> Why the hell is the portable Gpio API used for drivers, which are not
>> portable themselves?
>>
>
> In the case for AVR32 (where I suspect most of the calls you mention
> comes from), each peripheral must initialize it's pin alternative
> before use. The USART0 TX for instance can have as many as 4
> alternative pins in the physical chip. This is done in the
> Gpio{Port|Pin}ConfigSet. Since this is done only during
> initialization, and that part is just as fast as you can't notice, it
> just didn't matter if it could be faster or not. So it happens that
> when porting I did not care to provide any AVR32 specific faster way
> of doing that, the portable was just good enough.
>

Ah, yes that is a good point too:

Why should I write a function that configures my GPIO in a matter of the 
general API that provides just some sub set of options and then write a 
second one that provides the options that I need for my driver?

You have to carefully think which one to call, you have to tell API 
users, that there is something hidden, he needs, but cannot access.
You have to keep two different functions in the flash that both need 
function entry and function exit code.
And normally the one function is just the missing switch() case part 
that could have been added to the other function.

And, with Cortex (and many other ARMs) it is needed to enable GPIO 
peripheral clocks first before you can setup anything inside. So if you 
think of providing high-level and low-level setup functions you have to 
add clock setup to both of them too, what either adds again function 
entry/exit code for a clock setup function or it duplicates the code if 
it is included in both functions.

Ulrich