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

[Harald Kipp]

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.

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


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

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

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.


> 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))

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.

Regards,

Harald