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

[Uwe Bonnes]

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

    Ulrich> Accepted with, sorry, some simple minimal comments:
    >> 9.3 With NUTDEBUG defined, it is usefull if a possible much slower
    >> codepath is taken that checks for parameter validity.

    Ulrich> This might get difficult if you need / like to write an atomic /
    Ulrich> thread safe GPIO access. But we didn't commit to provide a
    Ulrich> standardized atomic port or pin access function, did we?

Well, I think of the NutDebug GPIO Code like e.g. 

#if NUTDEBUG
GpioSetPinLow(int port, int pin) {
asserts (<port is valid> && <pin_is_valid>);
  *(GpioTypeDef*)port->BSRR = (1<<pin);
}
endif

And the macro code would be
#define GpioSetPinLow(port, pin)  *(GpioTypeDef*)(port)->BSRR= (1<<(pin))

Thats still atomic in both cases. But to my knowledge, the macro give the
preprocessor/compiler the best chance to expand to minimal code, exactly one
command when port/pin are known at compile time. And it still produces the
right code even with port or pin not are known at compile time. But the
macro doesn't check for parameter validity. The NutDebug code however needs
a subroutine call. And if port is unknown at compile time, it must compare
port against a list of all ports on that CPU. The Port access is still
atomic, but we have a lot of overhead. The NUTDEBUG code however is usefull,
as it helps debugging.

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

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