[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
ulrich.prinz at googlemail.com
Mon Oct 15 22:25:07 CEST 2012
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
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
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
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
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!
More information about the En-Nut-Discussion