Re: [avr-libc-dev] [Bug #3327] I read from phorum that outb() is deprecated? But still can found a note from library "Use outb

[Theodore A. Roth]

On Sat, 3 May 2003, Joerg Wunsch wrote:

:)As Theodore A. Roth wrote:
:)
:)> Not so much portability, but a valid point:
:)>   http://www.egnite.de/pipermail/en-nut-discussion/2003-April/000670.html
:)
:)I wholeheartedly disagree.
:)
:)Whenever someone wants cross-platform portability like this, he needs
:)to establish a hardware abstraction layer anyway (if all goes well,
:)this could be completely handled on the C preprocessor level, thus no
:)additional overhead).  Relying on a particular feature of the library
:)of the supported platforms cannot replace this.  What meaning would
:)have »PORTD« on an IA32 machine running Windows, anyway?  (Besides, i
:)personally don't see any point in porting a real-time OS on top of a
:)non-realtime OS, as Windows or Unix...)
:)
:)> Also, It's conceivable that someone could want to use a chunk of on
:)> linux (using direct io access) or some other system and avr.
:)
:)Ironically, that's the best counterexample you're providing here,
:)Ted. :-)
:)
:)Remember it's been Linux that started with the »wrong« (illogical)
:)order of arguments in its outb() macro (and supposedly, it poisoned
:)from there into the first version of avr-libc).  So by using outb(),
:)you're particularly unportable especially between Linux and
:)avr-libc. ;-)
:)
:)Again, if such is the intention, the only way to get around it is a
:)separate HAL, which in its simplest form, could look like:
:)
:)#if defined __AVR__
:)#define OUTB(p, v) p = v
:)#elif defined __linux__
:)#define OUTB(p, v) outb(v, p)
:)#elif defined __FreeBSD__
:)#define OUTB(p, v) outb(p, v)
:)#else
:)#error "Don't know how to define OUTB on your system"
:)#endif
:)
:)OTOH, when talking about portability issues, i think our first and
:)foremost concern should be source-level portability to other C
:)compilers on the AVR platform (as well as the C code snippets that
:)could be found in Atmel's docs).  That way, it makes sense to
:)deprecate inb()/outb(), and tell the people to prefer the direct
:)assignment option instead.  IMHO, this is also better readable, but
:)that's just an opinion.
:)
:)Second, portability to other microcontrollers comes to mind.  Perhaps
:)one of the closest relative here is the TI MSP430 controller series,
:)because it's a modern controller (unlike MCS51, again an opinion only,
:)no religious wars please ;-), and it's supported by GCC (unlike PIC,
:)for example).  Incidentally, msp430-gcc uses the same direct assigment
:)form as we (which doesn't surprise since IMHO, the MSP430 uses MMIO).
:)

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. I will reopen the bug report and make the changes to the 
documentation.

Joerg,

Thanks for talking the time to write the detailed discussion. When I wrote 
my arguments, I knew they were weak and was hoping someone would either 
stregthen them or shoot them down. Looks like they went down in flames. ;-)

Ted Roth