[En-Nut-Discussion] Rational for RFA_5: Nut/OS GPIO AP

[Ole Reinhardt]

Hi Uwe,

> sorry, I have to bring up the GPIO Api again. In another mail I will send the
> real RFA_5 proposal

Sorry, but I strongly agree with Harald! The initial idea of this API
got lost over all the discussion. With my RFA I tried to keep the idea
compatible with the initial idea:

- API compatible with existing applications
- Easy to implement
- Not necessary the fastest way, but simple to implement


I also added guidelines to enhance the API with platform specific
extensions without braking the existing minimal generic API.




In contrary to this, your intention is based on a few requirements of
your very specific drivers, but you lost the generic view.



Why do you spend so much time in creating a GPIO api that will best fit
to your Onewire driver instead of creating e.g. a OneWire BUS API, which
allows the architecture maintainers to create an architecture specific
backend driver which will result in the fastest and optimal code
possible?




Now some comments to your RFA 5

4:  Why have you removed GpioCfgAlternateFunction()?

    you wrote:
    - Ole posed restrictions on the family internal GPIO implementation.
      This is _not_ scope of the platform independant API!

    I did not propose _restrictions_ but GUIDELINES how to extend the
    API with platform specific extensions. GpioCfgAlternateFunction() is
    also just a guideline, not a restriction!


10: You created a new set of flags to _initialise_ the I/O pins, but I
    don't see a word about configuring it later! 


11: "The user application may request following additional pin
     configurations"

     How can a application _request_ something? 

     I suggested to implement further flags (which exceed the basic API
     possibilities) in GpioPinConfigSetExtended().

     My intention by adding this function was not to end up in a 64
     bit / 128 bit, ... wide set of flags, to allow each and every
     platform specific enhancement, but to keep the generic flags
     minimal and to add everything else in a platform specific header.

     Why have you completely removed this idea?


     You wrote:
	(11.2) If pin configuration flags are treated as implementation
	hints, I see no harm done if additional flags are common
        defined.

     That's exactly the point. You will end up with hundrets of flags
     in gpio.h. As long as you treat the flags just as a hint, the user
     will never know which flags are implemented on his architecture. If
     the extensions are implemented as such and are defined in a
     platform specific header, the user will get a compiler warning if
     the flag is _not_ implemented.



13:  Why have you deleted this point?

15:  Why have you deleted this point?

> 6. Do GPIO actions beside configuration reasonable fast so that a bitbanging
>    one-wire driver has good chances to work. Time requirements for one-wire
>    are in the microsecond range.

I know, but even on an AVR where you have to emulate the open drain mode
with several calls to the API you will easily be fast enough. 

> C: Implementation constraint is to implement GPIO without the need for
>    memory to keep track of pin state and configuration

Sure this should be the goal, but in case you can not manage it, don't
try to modify the api but live with this disadvantage. You can never
know which problems may later arise on new platforms.




> Executive's summary:
> ===================
> If anybody has a _real_ implementation pending so that my thoughts and
> proposals are void or void (part for) his work, please let me know and reject
> RFA_5. 

I don't have one yet. But I would like to know why you abolished my
ideas for extending the api and why you did not stay with the basic
configuration flags.


I realy can't see any single problem why the existing API of RFA 4 may
not be enough to implement any of your usecases. (perhaps with having
two calls to the API instead of one for some functions). 


Bye,

Ole


-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280