[Top][All Lists]

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

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

From: E. Weddington
Subject: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Thu, 08 Sep 2005 05:05:43 -0600
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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?


reply via email to

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