[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

From: Joerg Wunsch
Subject: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Thu, 8 Sep 2005 22:51:16 +0200
User-agent: Mutt/

As Wojtek Kaniewski wrote:

> >#include <avr/generic/uart.h>

> >supposedly providing a generic uniform UART view for as many as
> >possible AVRs.

> Consequently, why not move <avr/io.h> to <avr/generic/io.h>? It's
> there to provide generic access to SFR's regardless of MCU used ;-)

Not really.  <avr/io.h> provides whatever the datasheet says.

<avr/generic/uart.h> provides an abstracted UART interface, so
regardless of whether that MCU's datasheet calls the major UART status
register USR or UCSRA or UCSR0A, you can write an application that
just uses one of those names, and gets the common functionality on all

My only concern is to not pollute the include/avr subdirectory itself
too much.

> >Except you'd need to explain them what cbi means as it's not a C
> >standard, and could mean anything else beyond occasionally
> >generating a CBI instruction. ;-)

> They already knew what cbi() and sbi() did...

They assumed they knew it. ;-)

How about:

uint8_t x;
sbi(x, 2);

That did work, but set anything else but a bit in an IO register. ;-)

I'm rather in favour of Eric Weddington's proposed <util/bit.h> that
contains generic bit manipulation macros.

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

reply via email to

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