[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: Wojtek Kaniewski
Subject: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Thu, 08 Sep 2005 22:11:05 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

Joerg Wunsch wrote:
Would people find it annoying to add another subdir level?  So then,
all "generic IO" headers could e.g. go into avr/generic/, the include
statement would then be

#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 ;-)

That would be great. I wouldn't have to explain my friends what does
"PORTD&=~_BV(4);" mean (-;

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, without studying the whole C standard. When these macros suddenly disappeared after the upgrade of their favorite AVR development suite they had to get into details like bitwise operators. But I don't want to start another flamewar, it just would be nice if the macros were still somewhere around.

Half point.  To compare it to my original complaint about the
interrupt helpers, we didn't name one fdevopen() and the other one

I found the underscores in the new names to improve readability, yet I
wouldn't want to rename fdevopen() as it's an established interface.
(fdevopen() has once been chosen as an analogy to fopen().)

Okay, I just wanted to point some future issues. If you're sure that these functions are called like they should be, it's fine.


reply via email to

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