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

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Wed Oct 24 11:24:17 CEST 2012


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

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

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

Sorry, I can't match what you say above with "man assert". I understand your
wording above as if assert() only checks during compile
time. Do you mean assert() in general or is this special behaviour of
NUTASSERT.

Experiments on Linux like
#include <assert.h>

int main(void)
{

    assert (1 == 0);
    return 0;
}

show assert() is a _run_ time check.


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

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

Again, I don't understand what you mean. If the code is compiled with
runtime check like POSIX assert() enabled, timing doesn't change from one
moment to the other. If you mean that timing sensitive GPIO like one-wire
bus fails with run-time check enabled but runs run-time check disabled, I 
agree.

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

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


More information about the En-Nut-Discussion mailing list