[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 Istvan
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Fri, 09 Sep 2005 10:40:30 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Wojtek Kaniewski wrote:

Joerg Wunsch wrote:

My only concern is to not pollute the include/avr subdirectory itself
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 noone (supposed) using them (notice the questionmark ---^, 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> that
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 : http://szm.no-ip.com/~szir/gcc/mydata.h
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 an <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 like 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(), inp(), etc. ad naseum. :-)

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

Yepp, its not very readable

- Our previous offline discussion of having a <util/*> tree would be 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 that we have discussed.

Is there any policy for supporting some additional hardware? It would 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 completly 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]