RE: [avr-gcc-list] What Happened to the sbi() and cbi() Macros????

[Ben Mann]

Nice to see some lively debate going on!

My 2 cents:

1) Even newbies should learn bitwise operations. When interviewing
prospective engineers (and not just embedded) I give them a small
handwritten C task which usually involves this, and consider it one of their
essential C skills. Those that can do this are consistently good performers.

2) SBI and CBI take their names from AVR assembler, but are not used the
same way. If you ask non-AVR programmers to debug AVR code they will spend
time researching SBI() but would have quickly understood PORTF |= ... and
intuitively guessed (eg) SET_BIT(). A good IDE might context-display the SBI
definition - but if you need to look at that why have the macro??

3) A generic bit-operations API would and should have far-reaching scope,
beyond the AVR environment. While many of us are having to hand-assemble
interrupt handlers to get around AVR-GCC's occasionally long-winded and
inefficient prologue/epilogue, I think that a noob api seems a huge
distraction. (If noobs don't understand bitwise operators and pointers, then
wouldn't BASIC be more relevant?)

4) Deprecating a library feature is fine in principle, but removing it
completely caused a little consternation. It would seem ideal for all
AVR-GCC users to be able to _compile_ legacy AVR-GCC code. For that reason
I'd vote for the inclusion of a new <avr/legacy.h> or similar. Old
deprecated apis can be supported (only) here. The action of #including the
legacy header makes people aware of the problem without revisiting ,000's of
lines of code.

- IMHO the role of AVR-LIBC and AVR-GCC is to enable the C-language to
interface to the AVR and **abstract us away from the assembler**. SBI/CBI
and bitwise helper-macros do not appear to fall into this scope.

- Coding practice may be deeply personal for many people, but in my case
readability - use of symbolic constants and meaningful names etc - comes
well before brevity.

Regards

Ben Mann