Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.]

[Joerg Wunsch]

As Dmitry K. wrote:

> Opinion of the simple user: it is time to collect personal library
> which will be inaccessible to fans of "deprecation".

Please elaborate.  If you have any reason to still use one of the
constructs that has been marked deprecated (or is currently discussed
to be), please speak up.

So far, deprecation affected the following items, included the
reasoning:

. timer_enable_int() and enable_external_int()

Both perform really simple operations on their respective interrupt
masking register which aren't worth a private macro or inline function
in any way.  The API was flawed in several ways.  The entire byte for
the bit masks needed to be passed each time, so the application had to
track in a separate variable which bits are currently set and which
aren't.  For the ATmega128 at least, there are now two registers for
the timer interrupt bit masks, so timer_enable_int() is pretty
pointless.  Finally, the code as it is causes an #error to trigger for
the AT86RF401 chip since that one doesn't have any external interrupt
mask register.

The only advantage of this was to provide a chip-independent method to
activate external interrupts, regardless of the actual name of the
external interrupt mask register (EIMSK, GIMSK, GICR).  However, this
could be solved by providing a generic register name definition in
another header file instead, say <compat/io.h> or maybe
<avr/genericio.h>, something that is needed for many other commonly
found AVR features as well (different names of the UART registers
between different AVRs come to mind).  There was consensus that such a
compatibility header would be worth the while, but nobody drafted one
so far.

. inb(), inp(), outb(), outp(), sbi(), cbi()

These macros/inline functions have all been private hacks from avr-gcc
that were invented by a time when avr-gcc itself was not smart enough
to handle the direct assignment form for IO registers (and to optimize
it properly).  Now avr-gcc can do this, so there's no longer a
justification for these hacks.  They make code written for avr-gcc
artificially incompatible with other C compilers for the AVR platform
(all the Atmel examples use the direct assignment form as well), and i
personally found that apart from ``I've always been doing it that way''
the most frequent reason why people in particular tend to use sbi()
and cbi() is that they believe them to be more efficient than writing
the generic C expression REG |= _BV(BIT); or REG &= ~_BV(BIT);.  They
simply don't realize that both are exact equivalents.  In particular,
if you don't optimize (-O0), /both/ forms cause the same inefficient
code to be generated.

In addition, outp() had an illogical order of arguments.

. eeprom_rb(), eeprom_wb(), eeprom_rw()

They have been deprecated in favour of a consistent namespace for
EEPROM handling functions, using the longer but more descriptive names
(like eeprom_read_byte()) instead.  Previously, there has been a mix
of short and long names.

. BV()

Has been deprecated in favour of _BV() since the name without the
underscore is more risky to clash with a name in the application
namespace (i. e. one that can legitimately be defined by the user).

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/