[avr-gcc-list] Does longjmp() work with avr6?
Hi. Traditionally Avr-libc's longjmp() function uses the 'eijmp' instruction to make jump (and destroys EIND register). Does avr6 GCC extension known about this? And, in general, what is the status of EIND register? Is it needed to save/restore in assembler functions? In inline assembler? Thanks, Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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.
Have I got the number declaration right?
Ron
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] RE: Class Interrupts
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Ron Kreymborg
Sent: Monday, March 24, 2008 2:28 PM
To: 'Marek Michalkiewicz'
Cc: 'Joerg Wunsch'; avr-gcc-list@nongnu.org
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
be:
void __vector_9 (void)
__attribute__ ((signal,used,externally_visible));
void __vector_9 (void) {
Or:
void MyTimer0OvfInt(void)
__attribute__((signal,9,used,externally_visible));
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
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] RE: Class Interrupts
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
be:
void __vector_9 (void)
__attribute__ ((signal,used,externally_visible));
void __vector_9 (void) {
Or:
void MyTimer0OvfInt(void)
__attribute__((signal,9,used,externally_visible));
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
Ok. I would have thought that makes for confusion, but I guess those using
this method can be assumed to be the cognisenti.
Ron
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
