[En-Nut-Discussion] RFA_4: Nut/OS GPIO API

[Uwe Bonnes]

>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:
Ulrich,

how many angles acommpanie you with your dance on the needle's pin?

Are we talking about the same thing here? Do you intend to write an
controller for an intercontinental missile as sample application for
nut/app? 

    Ulrich> Ok, slowly not again to mess up things.

    Ulrich> If you need to keep a certain timing, it is important that
    Ulrich> simple routines never alter their timing.

And you need a generalized portable appoach to work out of the box for
multiple architectures to work even with NUTDEBUG enabled? Forget portable
GPIO, write a target specific driver. Don't abuse portable GPIO!

But it _works_ for many cases and so we can put example usage in
nut/app. And without NUTDEBUG, the resulting code of the portable API will
be as good as hand-crafted direct register access.

...

    Ulrich> So my suggestion was: Add the warning to the RFA, that enabling
    Ulrich> debug may alter the timing of the GPIO functions. That doesn't
    Ulrich> cost anything but they are warned.

So why don't you tell us what you think is wrong with
>From  RFA_4
9.3 With NUTDEBUG defined, is is usefull if a possible much slower
    codepath is taken that checks for parameter validity.
>End from RFA_4

If you bring up new issues without referring to already proposed solution,
the discussion gets tedious.


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

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