First I would like to note that it is great that there is activity again on the development of mspgcc. Porting our 3.2.3 compatible code didn't cause much trouble, but there is one issue that I can not solve in a clean way and I am unable to find answers on on the internet.
In our code the interrupt handlers are written in assembler. The include files needed for this where io.h and signal.h, and an interrupt handler would like this:
interrupt(ADC12_VECTOR)
int_adc:
Now, in msp43-gcc 4.5.3 this method is apparently marked obsolete and moved to legacymsp430.h. Also io.h is obsolete and msp430.h is included. Doing so however, will generate the following error in the assembler:
Error:unknownopcode`vector_(0x0000):'
The vectors are defined in the device specific header file. Removing the brackets "(" and ")" then removes the error and everything will link just fine.
But it then turns out that there is still no ISR handler. This is probable because the token formed by the interrupt(x) macro is not redirected to an actual ISR label. This used to be done in signal.h like:
#define vector_0 vector_ffc0
But I could not find anything like that in any of the header files. I thus added them myself using:
#define vector_0x0000 __isr_0
I found the __isr_x entries in the mapfile where they were linked by some std object file.
After this hacking everything worked as expected, but it is not the way I would like it to make it work. Apparently this method of declaring an ISR is obsolete, but nowhere it is stated what is the right way. Does anybody know how to do it right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The previous toolchain policy was to use a symbol that encoded the vector location in the name. Because the interrupt vector base location is different on different MCUs (0xFF80, 0xFFC0, or 0xFFE0, and one odd-ball at 0x1C60) the current toolchain expects a global symbol __isr_X to be defined, where X is the word offset from the interrupt base address. The constants in the header are, unfortunately, the byte offset from the base. The compiler converts the information from the __attribute__((__interrupt__(ADC12_VECTOR))) specification in C into the correct value, but in assembler it's not possible to use the preprocessor to do so. You'll have to hand-code them. If you'd like an alternative approach for assembler, please open a tracker ticket at https://sourceforge.net/tracker/?func=add&group_id=42303&atid=432701.
For historical reasons, _reset_vector__ is still used as the symbol for RESET_VECTOR regardless of the number of supported interrupts.
If you could, please direct questions like this to mspgcc-users@lists.sourceforge.net, where more people will see it and responses will get archived where google can find them. That I haven't disabled this forum is probably a mistake.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
First I would like to note that it is great that there is activity again on the development of mspgcc. Porting our 3.2.3 compatible code didn't cause much trouble, but there is one issue that I can not solve in a clean way and I am unable to find answers on on the internet.
In our code the interrupt handlers are written in assembler. The include files needed for this where io.h and signal.h, and an interrupt handler would like this:
Now, in msp43-gcc 4.5.3 this method is apparently marked obsolete and moved to legacymsp430.h. Also io.h is obsolete and msp430.h is included. Doing so however, will generate the following error in the assembler:
The vectors are defined in the device specific header file. Removing the brackets "(" and ")" then removes the error and everything will link just fine.
But it then turns out that there is still no ISR handler. This is probable because the token formed by the interrupt(x) macro is not redirected to an actual ISR label. This used to be done in signal.h like:
But I could not find anything like that in any of the header files. I thus added them myself using:
I found the __isr_x entries in the mapfile where they were linked by some std object file.
After this hacking everything worked as expected, but it is not the way I would like it to make it work. Apparently this method of declaring an ISR is obsolete, but nowhere it is stated what is the right way. Does anybody know how to do it right?
I wasn't aware of any use of or support for the convenience macros for interrupt declarations in assembler code. The warning that's present when using isr_compat.h has been fixed in the development version; see https://sourceforge.net/tracker/?func=detail&aid=3414424&group_id=42303&atid=432701 for more details.
The previous toolchain policy was to use a symbol that encoded the vector location in the name. Because the interrupt vector base location is different on different MCUs (0xFF80, 0xFFC0, or 0xFFE0, and one odd-ball at 0x1C60) the current toolchain expects a global symbol __isr_X to be defined, where X is the word offset from the interrupt base address. The constants in the header are, unfortunately, the byte offset from the base. The compiler converts the information from the __attribute__((__interrupt__(ADC12_VECTOR))) specification in C into the correct value, but in assembler it's not possible to use the preprocessor to do so. You'll have to hand-code them. If you'd like an alternative approach for assembler, please open a tracker ticket at https://sourceforge.net/tracker/?func=add&group_id=42303&atid=432701.
For historical reasons, _reset_vector__ is still used as the symbol for RESET_VECTOR regardless of the number of supported interrupts.
If you could, please direct questions like this to mspgcc-users@lists.sourceforge.net, where more people will see it and responses will get archived where google can find them. That I haven't disabled this forum is probably a mistake.