[Top][All Lists]

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

RE: [avr-gcc-list] RE: Class Interrupts

From: Weddington, Eric
Subject: RE: [avr-gcc-list] RE: Class Interrupts
Date: Mon, 24 Mar 2008 15:16:30 -0600


> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Ron Kreymborg
> Sent: Monday, March 24, 2008 2:28 PM
> To: 'Marek Michalkiewicz'
> Cc: 'Joerg Wunsch'; address@hidden
> Subject: RE: [avr-gcc-list] RE: Class Interrupts
> > The idea was not mine - based on msp430-gcc where the "interrupt"
> > function attribute expects the vector number as argument.
> > 
> > Hope this helps,
> > Marek
> Therefore as a specification then: The intent of this patch is so an
> interrupt function for, say, a mega8 timer0 overflow can be 
> declared as:
> ISR(TIMER2_OVF_vect) {
> Or even as:
> void __vector_9 (void)
>      __attribute__ ((signal,used,externally_visible));
> void __vector_9 (void) {
> Or most importantly as:
> void MyTimer0OvfInt(void)
>       __attribute__((signal,10,used,externally_visible));
> void MyTimer0OvfInt(void) {
> Where the number in the last case is, of course, taken 
> directly from the
> Atmel vector table in the specification for the respective 
> processor and
> adjusted as necessary by the compiler.

My only objection is that the number vector correspond to normal
avr-libc usage and NOT from the Atmel datasheet, where avr-libc usage is
zero-based and one off from the datasheet. I would rather the options

void __vector_9 (void)
     __attribute__ ((signal,used,externally_visible));
void __vector_9 (void) {

void MyTimer0OvfInt(void)
void MyTimer0OvfInt(void) {

If they are the same number, then it avoids confusion. I know it doesn't
match the datasheet, but we have already established the precedent, and
I would rather be internally consistent.

Eric Weddington

reply via email to

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