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

[Szikra Istvan]

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.


Regards,
Istvan Szikra