[Top][All Lists]

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

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

From: Szikra István
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Fri, 9 Sep 2005 07:08:23 -0500
User-agent: Internet Messaging Program (IMP) 3.2.2

Wojtek Kaniewski wrote:

> Joerg Wunsch wrote:
>> My only concern is to not pollute the include/avr subdirectory
>> too much.
> I'd prefer those functions to be in <util/*> than <avr/generic/*>.
Me too
and, if it avr specific than rather <avr/util/*> than <avr/generic/*>

i also suggest moving <avr/io?*.h> to something like <avr/ios/io?*.h>

since no one (supposed) using them
(notice the question mark ---^, so io.h would still be <avr/io.h>, but

the device specific io headers won't populate the avr/ subdirectory )

>> I'm rather in favour of Eric Weddington's proposed <util/bit.h>
>> contains generic bit manipulation macros.
> That would also be fine. Any macros would be better than explaining

> the '&=~'-nightmare.

I support it,
in fact i already have something like this (for personal usage, since

it's not in RC1 stage yet)
If anyone interested in an alpha stage header : 
Maybe we should wait for Eric's version of bit.h.

Wojtek Kaniewski wrote:

> E. Weddington wrote:
>> - Going along with the theme, it would be good to eventually have
>> <avr/timer.h> header that deals with timers. Again, I have some 
>> possible candidates as a starting point.
> Is this header along with <avr/extint.h> available somewhere? I'd
> to take a look at it.

Me too

>> - I think your idea of <avr/deprecated.h> is a great idea! We could

>> put all of those outdated macros in it: sbi(), cbi(), outp(),
>> etc. ad naseum. :-)
> That would be great. I wouldn't have to explain my friends what does

> "PORTD&=~_BV(4);" mean (-;
Yep, its not very readable

>> - Our previous offline discussion of having a <util/*> tree would
>> good for "utility headers", i.e. headers that are nice, but not 
>> necessary, and that is not related to the AVR hardware. The first 
>> entry in this would be <util/bit.h> for bit manipulation macros
>> we have discussed.
> Is there any policy for supporting some additional hardware? It
> be nice if users got support for things like HD44780-compatible 
> displays or 1-Wire bus from the avr-libc, so they wouldn't need to 
> reinvent the wheel or deal with non-BSD licenses.
> BTW, <util/...> would be a good place for <avr/crc16.h> too.
Unfortunately crc16.h is not completely independent from avr hw on the

account it uses inline asm, and not (ansi) c.
So consider this before moving it. I suggest <avr/util/crc16.h>.
Plain C crc16, crc32, md5 should go to <util/*> but i dont know if it

avr-libc, or it should be just  libc.

Istvan Szikra

reply via email to

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