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

[Ulrich Prinz]

Ok, ok,

I just got the explanation of Uwes MULTIDRIVE and now understand the 
problem completely! MULTIDRIVE does not mean open collector but it means 
HIGHZ (high impedance). For AVR you have to write your data through the 
DIR register of a port than through the DATA register as it doesn't 
support highZ. For some ARMs you might need to do that too while for 
others a pin could be configured as HighZ.

So there are drivers that use the slow gpio system even they could be 
much more faster by using a 'private' gpio system. Not only that, they 
use tricks on that gpio system to emulate something that is not 
available on certain chips.

So we have to die one death or the other:
1) keep the driver slow but general
2) accept that good drivers are not available on all platforms as they 
use chip specific functions.
3) Split the driver to pieces that must be filled by the different 
architectures.


Am 15.10.2012 10:23, schrieb Harald Kipp:
> Hi Uwe,
>
> On 14.10.2012 22:12, Uwe Bonnes wrote:
>>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>>      Harald> May be you can, but I have my doubts, that anyone will maintain
>>      Harald> such a beast or port it easily to a new platform. It will be a
>>      Harald> PITS, which indeed hurts. ;-)
>>
>>      Harald> Ulrich, you are mainly explaining advantages of having an API
>>      Harald> for GPIO, which I did not put into question. My objection is,
>>      Harald> that this needs to be done in a portable API, available on all
>>      Harald> targets.
>>
>> Huch, where do we disagree now?
>>
>> Where do you disagree in the used of the Gpio API in owibus_bbif.c?
>
> I do not disagree with the implementation of owibus_bbif.c. This driver
> is designed to run on all platforms that provide Gpio. It must use the
> portable Gpio API.
>
> I disagree, for example, with arch\cm3\dev\stm\stm32_twi1.c. This is
> STM32 specific code and don't need to use the portable Gpio API.
>
> Several STM32 drivers extend the API with GPIO_PinAFConfig. Do you
> intend to integrate this into GpioPinConfigSet?
>
I am not sure what this will lead to... And I am not sure if the STM32 
is a good example. The GPIO code is as fast as possible, regardless if 
you put some PINCFG_xyz to a private file or a public one, there will be 
no additional code needed.

We could think about the part with the special-configurations, the thing 
you do if you switch of the GPIO function and connect the pin to a 
different periphery. Here I agree that it will get complicated.
Some chips only support 1 additional function, some many and others need 
multiple steps to switch a pin through a matrix till it is connected 
somewhere.

So from logical point of a programmers view I dismissed the pin from its 
GPIO function _after_ I switch it to a special service through the 
gpio-config function.

What we could think of is, that there is a switching function that 
selects a pins duty either as a GPIO or as a different thing.
If we then have configured it as a GPIO we provide some general working 
tokens to setup its physics as a GPIO pin. But we provide additional 
sets of chip specific functions too.

Switching the port as a different thing will be a complex thing that 
normally is done by the driver bringing the periphery to life that then 
handles the pin.

But these things are done by the driver guys that are more familiar with 
manuals of thousands of pages. So it should work even it uses bit-masks 
or special cryptic defines.

If we do it like this, we could keep a lot of compatibility. And we 
could keep it easy even we add _PULLUP10K or _HIGHZ for certain 
architectures.

This does not speed up drivers, using dirty tricks, but it's a driver. 
So if it works best for one architecture, you can adopt it for the 
other. If you as an adopter find out that it could be done better in a 
different way with your architecture, it's your chance!

Ulrich