extern "C" not understood by g++ ?

I suggest you try a minimal test program with a simpler use of extern "C", just to narrow down where the issue lies.

A single extern "C" function defined/declared in a .cpp/.h pair (compiled as C++), and called from a main function in a separate file compiled as C should help clarify what's going on.

Thanks for your suggestion.

1. Compiling a simple C / C++ mixture as you suggested worked fine. I guess then the problem lies in the file iomacros.h.

2. Switching on extra warnings revealed that 'extern' is not at beginning of declaration [-Wold-style-declaration]

3. Found the bug and a workaround :-)

Here's what's going on: Apparently extern "C" needs to be the first statement on the line or at least come before the const keyword. But on these lines in iomacros.h (close to the end) ...

#define const_sfrb(x,x_) const sfrb_(x,x_)
#define const_sfrw(x,x_) const sfrw_(x,x_)
#define const_sfra(x,x_) const sfra_(x,x_)
#define const_sfrl(x,x_) const sfrl_(x,x_)

... the const is inserted in the macro definition. This is resolved by the preprocessor to something like this ...

#define const_sfrw(x,x_) const extern "C" volatile unsigned int x asm(#x_)

... where the const comes before extern "C". As a workaround I removed the four lines above and inserted a complete #ifdef for every const_xxxx with the const after the extern "C":

#define const_sfrb(x,x_) extern "C" const volatile unsigned char x asm(#x_)
#define const_sfrw(x,x_) extern "C" const volatile unsigned int x asm(#x_)
# ...

This worked for me. I would supply a diff to fix this, but the workaround is ugly (much duplicated code) and I'm pretty unfamiliar with what's exactly going on in these macros. So maybe some insider can have a look at this and fix it?

Thanks

Christoph

I described my fix here;

http://forum.43oh.com/topic/5419-code-composer-studio-v6-now-officially-released/?p=47449

Christoph, your workaround is no workaround and it isn’t ugly, it simply is the way it has to be done. And it doesn’t generate any excess code. It is even a few microseconds faster when the precompiler parses the defines. :)

 Rick, I don’t know what your ‘fix’ shall be good for: you just deactivate the usage of the extern ”C” switch, so if the header file is included by a C file, the compiler will assume a different name for the register name than if compiled within a C++ file.
Well, in case of the sfrs, where the address is given explicitly and the compiler won’t generate relocatable references anyway (and the register never needs to be linked), this may work, but it won’t work for functions, not for library constants etc. And it won’t work for CCS and IAR, where the SFRs are linked by the linker and the compiler has to generate relocation entries that have to be resolved by the linker based on the (C) names that are stored in the linker script. Which is the way to go, as it allows generic header files instead of separate ones for each processor due to different register addresses.

 The reason for the existence of the extern “C” is that the C++ compiler renames each element, by adding its namespace and (in case of functions) the parameter types. This is required so different namespaces can have functions with same name, and multiple functions with different parameters can co-exist for operator overloading etc.
The extern “C makes the element a unique element that is available in all namespaces, just like a C compiler would generate and expect, as C doesn’t support namespaces or operator overloading.

Here is a simple .cpp file. When I try to compile with msp430-elf-g++ it falls down pretty quickly. Does this compile successfully for you Jens-Michael Gross?

// blinkled.cpp - simple c++ led blink

#include <msp430.h>

int main(void) {
  WDTCTL = WDTPW|WDTHOLD;

  P1DIR |= (BIT0|BIT6);
  P1OUT &= ~BIT0;
  P1OUT |= BIT6;
  for(;;){
    P1OUT ^= (BIT0|BIT6);
    __delay_cycles(250000); // delay
  }

  return 0;
}

$ msp430-elf-g++ blinkled.cpp -c -mmcu=msp430g2231
In file included from /home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:58:0,
                 from /home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430.h:1273,
                 from blinkled.cpp:3:
/home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:409:1: error: expected unqualified-id before string constant
 const_sfrb(P1IN, P1IN_);
 ^
/home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:426:1: error: expected unqualified-id before string constant
 const_sfrb(P2IN, P2IN_);
 ^
/home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:448:1: error: expected unqualified-id before string constant
 const_sfrw(TAIV, TAIV_);
 ^
/home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:692:1: error: expected unqualified-id before string constant
 const_sfrb(CALDCO_1MHZ, CALDCO_1MHZ_);
 ^
/home/kimballr/Msp430GCCopensource/msp430-elf/include/msp430g2231.h:694:1: error: expected unqualified-id before string constant
 const_sfrb(CALBC1_1MHZ, CALBC1_1MHZ_);
 ^

Jens-Michael Gross said:

Rick, I don’t know what your ‘fix’ shall be good for: you just deactivate the usage of the extern ”C” switch, so if the header file is included by a C file, the compiler will assume a different name for the register name than if compiled within a C++ file.

My quick hack works because when a c++ file includes iomacros.h via a device header such as "msp430.h" which then includes the "msp430g2553.h", that header wraps an extern "C" around everything including the iomacros.h header. So there is no need to explicitly do it in the iomacros.h file.

...

#ifndef __MSP430G2553
#define __MSP430G2553

#define __MSP430_HEADER_VERSION__ 1131

#define __MSP430_TI_HEADERS__

#ifdef __cplusplus
extern "C" {
#endif

#include <iomacros.h>

....

/************************************************************
* End of Modules
************************************************************/
#ifdef __cplusplus
}
#endif /* extern "C" */

#endif /* #ifndef __MSP430G2553 */

Actually it does. Even though I don’t know why one should use a cpp file when it contains plain C code.
But I’m using a different toolchain than you and different header files.
But try the following:

I'm going to stop talking about this as you obviously don't understand that this is a problem specific to iomacros.h that is shipping with the latest msp430-elf-gcc, not some arbitrary msp430-gcc compiler.

I submitted a post on the compiler forum. They have given me a bugzilla # and they understand the problem.

http://e2e.ti.com/support/development_tools/compiler/f/343/t/356902.aspx .. the other thread.

-rick

I completely do understand. And I never denied that there is a problem. However, your solution fixes the problem on the wrong end.