[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [Bug #3327] I read from phorum that outb() is deprec
Theodore A. Roth
Re: [avr-libc-dev] [Bug #3327] I read from phorum that outb() is deprecated? But still can found a note from library "Use outb
Mon, 5 May 2003 09:39:05 -0700 (PDT)
On Mon, 5 May 2003, Joerg Wunsch wrote:
:) As Theodore A. Roth wrote:
:) > Ok. Those arguments are compelling enough for me. I am now in
:) > agreement as to the deprecation of (and eventual removal of) the
:) > outb() and friends macros.
:) Well, we don't need to completely ban outb(), but the docs should
:) point out that it's effectively the same as the direct assignment
Well, my understanding was that if an interface is deprecated, it
will be removed eventually. The period of deprecation is for warning
users to switch their code to the preferred interface.
Ok, so are we deprecating it or not? I say deprecate it based on your
previous arguments (and my lack thereof). If a user can't life without
it, it is trivial for them to make their own version of it.
:) form. In particular it doesn't guarantee an OUT instruction will be
:) used. It uses the same MMIO paradigm internally, and with -O0 will
:) come out as (expensive) MMIO as well. For the upper registers on the
:) ATmega128, it can only translate into MMIO anyway, and for anything
:) else, the optimizer will turn it into an OUT instruction.
:) I think there's a discussion about the MMIO vs. separate IO space
:) instructions somewhere in the docs. This should probably be extended
:) to mention that the direct assigment form is preferable since it is
:) more in line with other AVR compilers. I'd volunteer to write a FAQ
:) entry "Why is outb() deprecated?" that summarizes this, and points to
:) the more detailed IO explanation. It could also discuss the need for
:) a separate HAL in projects where cross-platform portability is an
:) issue (just a sentence or two).
Please do that.