|Subject:||Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes|
|Date:||Fri, 09 Sep 2005 10:35:46 -0600|
|User-agent:||Mozilla Thunderbird 1.0 (Windows/20041206)|
Joerg Wunsch wrote:
As Wojtek Kaniewski wrote:Very good point. I've been thinking about adding a second set of vector names anyway. Our names are completely self-invented. In the long run, I'd rather like to migrate the names as they appear in the Atmel XML files, which incidentally also match those IAR is using. So e.g., SIG_INTERRUPT0 would get an alias named INT0_vect. Besides of being closer to the datasheet and XML specs, it provides for a rather easy option to write source code that is portable between IAR and GCC (as the remainder can be encapsulated in header files, now that IAR includes the C99 _Pragma() operator). As Royce Pereira wrote:In SDCC (mcs51 open source C compiler) one can name their ISR as anything, and then set an attribute to specify it as an ISR for a specific source.void zerocrossover(void) interrupt EXT0Can this be done with AVR-GCC and what would be the problems implementing this?Not easily. It would require massive changes in both, GCC and avr-libc, and I don't see any obvious advantage that would justify the effort required to do this.As Wojtek Kaniewski wrote: [about AVR generic IO abstraction headers]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/*>.I could live with that. Eric, does that match your intentions as well?
Hello All,I'm sorry I haven't kept up with the discussion as I should. So here's a scattershot of opinions:
- I like Zane's idea of ISR() too. There. Let's implement it! :-) Along with deprecating SIGNAL() and INTERRUPT().
- I like isr.h too. Combine interrupt.h and signal.h.- I like migrating the names to the same as in the AVR Studio XML files. It will definitely help in winning over IAR users. ;-) - I do like the idea that Royce has (above) about naming the ISR function any name. However, I agree with Joerg, in that it would take an awful lot of effort. Perhaps someday, but not now. - I'm sorry, but I don't necessarily care for having a further header subdirectory such as <avr/generic/*>. I still feel that it would belong in <avr/*>. My main argument is <avr/sleep.h> now has so much "cruft" because it supports many different processors. There is nothing different between what the <avr/sleep.h> header does and what a proposed <avr/uart.h> would do, in the sense that they both support many different processors, but they are both AVR-specific.
I'm sorry if I've missed any issues. Please correct me if I've missed something.
And then, with all the proposed changes, would this warrant a 2.0 release? Eric
|[Prev in Thread]||Current Thread||[Next in Thread]|