missing #define __interrupt __attribute__((__interrupt__))

Hi Kees,

I'm going to look into this and will get back to you.

Regards,
Katie

Hi Kees,

Is this different from what we currently use in our code examples?

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=UNMI_VECTOR
__interrupt void UNMI_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(UNMI_VECTOR))) UNMI_ISR (void)
#else
#error Compiler not supported!
#endif

As seen in our code examples like this:

When I build the msp430fr59xx_cs_03.c example linked above in CCS with compiler set to GNU v4.9.1 (RedHat), it seemed to work.

Regards,

Katie

Hello All,

I posted before, got response, but can find my original posting :-(  So again.

Code sample

prototype

void RetiFunction(void); 

function

__interrupt  void RetiFunction(void){}

produces error if

#define __interrupt __attribute__((__interrupt__))

in iomacros.h is absent

and builds if present

error

../Common/Misc/isrvec.c:143:14: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
 __interrupt  void RetiFunction(void){}

msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-167)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

best regards

Kees

Hello Katie,

I yet have to learn all the features of this support board. I posted again as I missed your notification mark.

Yes, it is different in a way that we only want to hint the compiler that the particular function runs under interrupt context, i.e. jumped from an assembly Interrupt handler.

By telling the compiler by __interrupt it will allow certain things in that code i.e. LMP3_EXIT; etc.

The marked line above also marks the code as for __interrupt but also defines the vector.

The lone #define __interrupt __attribute__((interrupt)) is highly desirable (and the "old" MSPGCC and IAR have it)

best regards

Kees

Hi Kees,

I merged the threads since it was on the same topic.

When you added the #define into iomacros.h, all works as expected, correct? Just double-checking. Also, to clarify - you are doing a mixed C and assembly project, and you have assembly code that is doing the interrupt handling (it is managing the interrupt entry/exit), and you want to use __interrupt to tell the compiler that a particular C function gets called from your assembly interrupt handling code, and so that it will know this function runs as part of an interrupt service routine and will treat it as such. Versus the current definition with giving it a vector, would cause the interrupt to go directly to this C-code instead of going through your assembly interrupt code first?

I also wanted to check - in the latest version of the GNU compiler (v4.9.1) that I have in CCS, I open iomacros.h and see the line:

#define __interrupt(vec) __attribute__((__interrupt__(vec)))

You are saying that you need     #define __interrupt __attribute__((interrupt)) instead of the current line (if you have both it would be redefining __interrupt, so would have to replace it), and also that older versions had __interrupt defined this way instead?

Thanks for bearing with me - I am not personally an expert on the GNU compiler for MSP (much more familiar with the TI C compiler) so I'm just trying to make sure that I understand all of your needs correctly. I will  talk to the team that supplies the support files for the device to see why this may have been changed, and I'll get back to you as soon as I hear back from them. 

Regards,

Katie

Hi Kees,

I finally got some feedback on this - they said that you "should be using the new macro along with TI header files and the appropriate vector argument."
But they also said that both of below are accepted by gcc compiler:

#define __interrupt(vec) __attribute__((__interrupt__(vec)))
#define __interrupt(vec) __attribute__((interrupt(vec)))

However, I think they are going to change the macro to #define __interrupt(vec) __attribute__((interrupt(vec))) going forward, based on your suggestion.

Regards,
Katie

Hello Katie,

The _main_ reason for '__interrupt' is the following. We write _inline_ interrupt handler codes and other interrupt handlers in C.

Some are (conditionally) inlined in our code base. Some are called from "high-speed" interrupt handlers in Assembly code.

To hint the compiler that this code runs directly in interrupt context we use

__interrupt void Handelercode(void)
{
do things....

i.e. LPM1_EXIT;

}


Without the __interrupt directive the compiler would complain about the LPM1_EXIT statement.

The _OLD_ mspgcc had it's define in iomacros.h and the IAR compiler supports it natively.

best regards

Kees

Kees Schoenmakers said:

Without the __interrupt directive the compiler would complain about the LPM1_EXIT statement.

The _OLD_ mspgcc had it's define in iomacros.h and the IAR compiler supports it natively.

I think this puts the finger on the problem. Compilers like IAR and CCS has been using the __interrupt keyword for about 20 years. There are tons of code written using this convention.

The original GCC header file definition of __interrupt (without the "vec" parameter) was written to be backward compatible with existing code. The new version (with the "vec" argument) isn't.

One suggestion is to define a new macro, say __interrupt_with_vector(vec), that could be used along the existing one. It would probably be possible to define versions of this macro for IAR and CSS, so code would work in many environments.

    -- Anders Lindgren, IAR Systems, Author of the IAR compiler for MSP430