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

[Ulrich Prinz]

Am 14.10.2012 13:07, schrieb Harald Kipp:
> Hi Uwe,
>
>
>> My work on the AVR showed, that even for that arch you could defined the
>> GpioApi in a way that will result in most cases in the single commands sbi()
>> and cbi() as would unportable direct coding. And even
>> the bank argument as a runtime variable can be handled without a big runtime
>> switch case but by a pointer access if you look at the three consecutive AVR
>> port/pin/ddr register as a structure.
>
> Which is probably an advantage. But still there is no reason for me to
> use this API in AVR-specific drivers.

But, if the API is effective and fast, why _not_ using it? Why making 
porting of the OS difficult? If you take a different chip as a reference 
to implement your chip, you will need your time to understand why a user 
carefully developed a fast GPIO driver and then is not using it...
If the API code is not fast and effective... change the code ;)

Ah, and there are modes that are special for GPIOs of certain chips 
which obviously are not needed by any GPIO API... Like switching a GPIO 
to a different function or to its 2nd function or whatever.

I say that this is the wrong way to handle it.
1) You need this option for your drivers. So writing a serial port 
driver requires to switch the designated pint to serial port functions.
So you have to implement it in any case.
2) You might not implement all and any available peripheral system the 
chip provides, so give others all instruments you already developed, so 
they can learn and use them quick and later submit their drivers to the 
community.

Ulrich