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

[Ulrich Prinz]

I just wanted to warn, not extend the discussion. Just keep the warning 
in the RFA, that's all.

In you rexample,
asserts (<port is valid> && <pin_is_valid>)
highly depends if both conditions can be decoded to conditions without 
variables in pass one by the compiler. So I would consider this as only 
90% true.

But normally users will write their code for a certain platform an will 
check that the pin is valid and the port is available.
We additionally defined, that the port and pin can be detected for 
availability and support of a certain function by the appropriate setup 
functions. So we are on safe ground.

There is only a slight chance that someone is going nuts while trying to 
figure out why his timing is going wrong, while seconds ago it perfectly 
worked...

Ulrich

Am 20.10.2012 17:49, schrieb 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
>