avr-libc-dev
[Top][All Lists]
Advanced

[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


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] [Bug #3327] I read from phorum that outb() is deprecated? But still can found a note from library "Use outb
Date: Sat, 3 May 2003 09:46:02 +0200
User-agent: Mutt/1.2.5i

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).
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]