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

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi Ulrich, On 14.10.2012 18:55, Ulrich Prinz wrote:

    >> 1) Q) Why general function set for GPIO access, not a special one for
    >> high-level and low-level programming?
    >> 
    >> A) For STM32 there is no need to use separate APIs for GPIO as the
    >> API functions are already the fastest way to access GPIO. So there is
    >> only one function set available.

    Harald> Which is getting more and more complicated, because other chips
    Harald> do not provide GPIO_CFG_SPEED_FAST and STM32 doesn't provide
    Harald> GPIO_CFG_SLEWCTRL and the next platform will demand
    Harald> GPIO_CFG_SLEWCTRL only if GPIO_CFG_SPEED_FAST is not set...and
    Harald> so on...

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.

    >> 2) Q) Why do I feel that a separate GPIO access is obsolete?
    >> 
    >> A) If you are porting a new chip, you might think that you need
    >> comfortable and easy access GPIO functions and you know that the AVR
    >> example is the easiest one to understand. But then, with the first
    >> RS485 driver, where you have to switch bus direction using your own
    >> GPIO access functions, you learn that GPIO access times might be
    >> relevant to system performance. So you do the work, you should have
    >> done at the beginning, just a little bit later.

    Harald> Sorry, I cannot follow. What I understood was, that by
    Harald> convention something like

    Harald> port1.outreg |= 1 << 0;

    Harald> is used for many ARM targets to set bit 0 of an output port to
    Harald> 1. If you need target specific functions, one would use

    Harald> port1.special &= ~(1 << 0);

    Harald> to clear bit 0 in the special function register. What kind of
    Harald> _portable_ API would help here? You need to check the datasheet
    Harald> anyway.

    >> And at the end you ask yourself, why should I use a fast method to
    >> switch and control GPIOs in my low-level drivers, but only provide a
    >> complicated slow code to the API users?

    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.

    >> 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_.

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?

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------