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

[E. Weddington]

Wojtek Kaniewski wrote:

> E. Weddington wrote:
>
> > - I think it would be best to go ahead and deprecate 
> > timer_enable_int() and enable_external_int(). I agree that the naming 
> > wasn't very well thought out, perhaps.
>
>
> If naming consistency is important, then we should probably do 
> something about fdevopen() and fdev_*() too. All fdev functions except 
> fdevopen() use underscores.


Good point.

> > - 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.


Only on my machine. :-)
I'll post it to the avr-libc-dev list soon (with an RFC in the subject 
line).

> > - 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. That's the idea. However, note that evetually they would go away 
from that header. We would make it as annoying as possible to use 
anything deprecated. :-) The proposed <util/bit.h> would be helpful in 
your specific case above.

> > - 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.

This gets complicated.

One the one hand, avr-libc is supposed to provide a C library only, and 
we have extended it to support some of the on-board peripherals. I think 
we could, and should, do more to support the on-board peripherals. But 
that should be the extent of the avr-libc project.

On the other hand, I abhor reinventing the wheel and there should be a 
place for *exactly* what you describe: libraries to interface to common 
external peripherals, that have been vetted. The downside to this is 
twofold: the time it takes to verify the submitted code, and where to 
put it.

To further the cause, I will volunteer: Please submit code to me, or to 
the avr-libc-dev list, and I'll help pull it together in one single 
place. To help spread the load, I will ask that it be verified on real 
hardware by the submitter, and that it be a project that builds a 
library (so you had better know how to do that :-). There also needs to 
be a minimum of documentation. It can be a simple text file that 
describes what the library is used for, how it is used, etc. If you are 
connecting to an external hardware peripheral, please put in the name of 
the manufacturer, manufacturers part number(s), and it would be helpful 
if you had a link to the part's datasheet.

> BTW, <util/...> would be a good place for <avr/crc16.h> too.

Very good point. crc16.h has nothing to do with AVR hardware, but it is 
a very useful utility.
------

Joerg, what do you think about all these points?

Eric