Post by Test
/* below reads a digital input pin 5 and return 00010000 if it is "on"/"high" or
otherwise return 000000000 zero */
i4=kk>>g; // i4 will get integer 1 or zero
I would suggest using two "!" operators consecutively: kk=!!(GPIO_READ(5)),
or better yet, wrap that in a macro like
#define PUMP_READY() (!!(GPIO_READ(5))
If a compiler doesn't know that GPIO_READ(5) will always return 32 or 0,
then a statement like "if ((GPIO_READ(5)) >> 5) ..." would require the
compiler to perform a useless shift operation before branching. Most
compilers, however, should be able to recognize that a statement of the
form "if (!(condition)) X; else Y;" is equivalent to "if (condition) Y;
else X;", and thus "if (!!(condition)) X; else Y;" would be equivalent
to "if (condition) X; else Y;" without any extra steps. Since the most
common use of I/O reads would be as branch conditions, that's the most
important case to optimize.
With regard to operator precedence, either your form or mine should work
fine if the definition of GPIO_READ(x) is even remotely reasonable. Just
make sure that you have a set of parentheses directly around the invocation
of GPIO_READ and you should be set. Putting a set of parentheses around
the argument to GPIO_READ may or may not be a good idea. If your code
never passes anything to GPIO_READ other than macros that describe pins
and you never use those macros for any other purpose, then something like
#define PUMP_READY_PIN 23
#define GPIO_SET(x) (!!(GPIO_READ(x))
if (GPIO_READ(PUMP_READY_PIN)) ...
could be readily adapted to a GPIO-reading function that requires two
arguments, merely by changing the definition of PUMP_READY_PIN to e.g.
#define PUMP_READY_PIN PORTA,23
while everything else stayed the same. If GPIO_SET(x) had wrapped x in
parentheses, such a definition would fail if "x" could be a macro like
the second PUMP_READY_PIN definition.