[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
harald.kipp at egnite.de
Sun Oct 14 20:03:21 CEST 2012
On 14.10.2012 18:55, Ulrich Prinz wrote:
> 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.
Which is getting more and more complicated, because other chips do not
provide GPIO_CFG_SPEED_FAST and STM32 doesn't provide GPIO_CFG_SLEWCTRL
and the next platform will demand GPIO_CFG_SLEWCTRL only if
GPIO_CFG_SPEED_FAST is not set...and so on...
> 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.
Sorry, I cannot follow. What I understood was, that by convention
port1.outreg |= 1 << 0;
is used for many ARM targets to set bit 0 of an output port to 1. If you
need target specific functions, one would use
port1.special &= ~(1 << 0);
to clear bit 0 in the special function register. What kind of _portable_
API would help here? You need to check the datasheet 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?
IMHO, a portable Gpio API can never serve as a full replacement for
accessing I/O registers directly. Platforms are too different.
> 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))
Please correct me, if I'm wrong: You demand to press all functions of
all targets into a single, portable API, which will provide the optimal
code on all platforms.
May be you can, but I have my doubts, that anyone will maintain such a
beast or port it easily to a new platform. It will be a PITS, which
indeed hurts. ;-)
Ulrich, you are mainly explaining advantages of having an API for GPIO,
which I did not put into question. My objection is, that this needs to
be done in a portable API, available on all targets.
More information about the En-Nut-Discussion