[En-Nut-Discussion] RFA_4: Nut/OS GPIO API
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
Experiments on Linux like
assert (1 == 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
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