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

[Szikra István]

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 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>
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 (-;
>
Yep, 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 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.


Regards,
Istvan Szikra