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

[Ulrich Prinz]

Am 14.10.2012 22:12, schrieb Uwe Bonnes:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>
>
> GPIO_CFG_SLEWCTR or GPIO_CFG_SPEED_FAST are for use inside the architecture
> specific drivers. A problem arises _only_ if application code thought to run
> on many architectures by accident, bad style or not knowing better uses a
> chip specific GPIO setting in general code.
>
> So here I try to trigger since July a discussion for a common understanding
> of what to do in that case. So here again a plea to discuss!
>
> My best bet is that a architecture GPIO driver must know about all possible
> GPIO settings, but ignores settings it can't implement. If general user code
> really needs _this_ feature, it should get the GPIO settings with
> GpioPinConfigGet() to check that that feature was set by the preceeding call to
> GpioPinConfigSet() and if the feature is not set, explain to the user that
> the feature is needed and the programm can not run on that architecture.

Uh... Why not using a fast CPU and linux then?

I use Nut/OS cause it has a small footprint. I don't like the idea of 
adding code to avoid usage of things that cannot be used with my system 
by design. My preference would be to simply not implement such things or 
let usage of not implemented things being intercepted by the compiler.

Why should one write code for AVR and ARM that needs to access a GPIO 
extra feature deep down below the API?
If you write a web server demo code, you access the eth driver the 
architecture provides, not the special function registers inside the chip.

So in AVR there ist defined NUTGPIOCFG_INPUT, _OUTPUT, _PULLUP in
ARM these basic set is provided too but there are additional ones like
_PULLUP10K, _PULLUP24K, _PULLUP47K, _INPUTANALOG

Using NUTGPIOCFG_PULLUP47K should rise a compiler error as it is not 
defined in AVR_gpio.h but NUTGPIO_INPUTANALOG could be equal to 
NUTGPIO_INPUT in AVR as there is no difference.

>
>      Harald> IMHO, a portable Gpio API can never serve as a full replacement
>      Harald> for accessing I/O registers directly. Platforms are too
>      Harald> different.
>
> Harald, for AVR and STM it is shown that the GPIO API is as fast as
> unprotable code. And these platform are as different as one may
> imagine. Well, a 8051 architecture will probably need more care and
> thoughts, but at least AVR32 and AT91 have GPIO registers similar to
> STM32. I would care for AT91 too, if anybody would give me a hint how to
> flash and debug the damned Olimex board reliable.
>
That was ono my mind too:
Taking care means someone has to keep compliance but several people 
should share the work and keep an eye on their architecture. In this 
case the rules and naming conventions should be in the wiki and the 
drivers and API is per chip. You even cannot have the GPIO API on a per 
architecture basis as NXP has different options on their GPIOs than ST 
or TI have.

>      >> 3) Q) Why should I try to provide access to all features a chips
>      >> component has?
>      >>
>      >> A1) Because I could.  A2) Because there is always one person needing
>      >> exactly that thing that you thought of as obsolete.  A3) It doesn't
>      >> hurt, as here the same things apply that apply for the GPIO access
>      >> functions. Normally small chips just have little features for their
>      >> GPIOs (and their other peripherals too). So a small value is enough
>      >> for their features. I.e. for AVR a size_t or uint8_t should be fine
>      >> and all options could be addressed.  In one case NUTGPIO_PULLUP is
>      >> 0x02, in the other case it is 0x00020030 or even ((1<<PUE) | (1<<XEN)
>      >> | (2<<PURES))
>
>      Harald> Please correct me, if I'm wrong: You demand to press all
>      Harald> functions of all targets into a single, portable API, which will
>      Harald> provide the optimal code on all platforms.
>
> For optimum code you need a driver for each device and each
> platform. Bitbanging driver may not be optimum, but in many cases _good_
> _enough_.
>
And they stand an fall with the reliability of the GPIO framework behind 
them :)

> We demand the Gpio Api to be best effort and work an many cases. Nobody
> wants to replace the platform specific TWI/SPI drivers, but bitbang GPIO
> TWI/SPI drivers should work as alternative approach.
>
>      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?
>
Ok, I think we have a small misunderstanding in here now. We all want 
the same, but may be in different ways.

I want the gpio api to be defined on paper and programmed separately per 
chip. No gpio.c including #include "my_arch_gpio_sub.c" or something 
like that.
I'd like to see a gpio.c at every architecture or chip as needed. A 
gpio.h that is either created by nutconf or it selects the right 
arch_gpio.h if there is no way around this include-by-include.

And as it is an API, only names count. For one architecture pullup means 
5, for another it means 0x0020340.

Ulrich