This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C++ problems with CCS 4.1.2.00027

I am having trouble adding a .c++ file to my ccs4 project.

The project builds fine, but the map doesn't show the .obj file from the c++ file and I get wierd behavior with USB code that works otherwise.

The stellarisware code doesn't seem to have any C++ examples.  Why?

What settings do I need to change to accomidate C++.   Is there documentation I overlooked?

Is there a different entry point (c_init_00)?

Regards,

Larry

  • Hi Larry,

    I will confer with the software team and let you know what they say.  Stellarisware is done in C code, as that is what embedded code is written in.  The majority of complilers for embedded applications do not accomidate C++. 

    Lela

  • Lela Garofolo said:
    C code, ... is what embedded code is written in

    That's a rather sweeping generalisation!

    Certainly, in the kinds of system for which Stellaris-class microcontrollers are appropriate, 'C' is by far the commonest language - but C++ is gaining popularity.

    And, of course, other languages are available.

    Lela Garofolo said:
    The majority of complilers for embedded applications do not accomidate C++. 

    Is that actually true today?

    I would certainly think that the majority of compilers for ARM (including Cortex-3) now support C++ ?

  • I have tracked my problem down to a pure virtual base class, which was used as an "Interface"

    I ported code from an ARM9 / Greenhills project, which compiled and ran fine.  The code also builds and runs properly with Visual Studio 2005.

    I removed the interface class from the derived class definition and everything works now.

    NOTES:  The code I speark of was linked into the firmware but never executed, yet it still disrupted USB communications.  I don't know why?

    I suspect the "C" startup code did something bad.

     Is there a known issue with pure virtual classes?

  • Larry Harmon said:
    I ported code from an ARM9

    Hmmm.....  an ARM9 is quite a different beast from a Cortex-M3!

    For a start, doesn't it have a Memory Management Unit (MMU) - and maybe something required that in order to support your "virtual classes"?

    Maybe also something to do with the Stack and/or Heap...?

  • Larry Harmon said:
    Is there a known issue with pure virtual classes?

    Not being really "into" C++, I couldn't say - but does this help: http://www.artima.com/cppsource/pure_virtual.html

     

  • The MMU was not used on the ARM9.  Anyways this has nothing to do with virtiual memory.  I'm talking about a C++ Virtual function.

    As for the heap or stack it could very well be.  But please remember the C++ class is never instantiated or invoked, just having the code compiled and linked in the image causes the problem.

  • Larry Harmon said:
    this has nothing to do with virtiual memory

    I realise that - but there could be something in the C++ runtime (eg, to do with dynamic allocation) that relies on the MMU?

    And, of course, there are other differences (besides the MMU) between ARM9 and Cortex-M3.

    Larry Harmon said:
    please remember the C++ class is never instantiated or invoked, just having the code compiled and linked in the image causes the problem.

    Indeed. But could still be something in the startup and/or runtime that prepares itself for a possible use?

    But you're right - I am clutching at straws!

  • Larry,

    I have confered with one of our software engineers, and he suggested that I move this forum thread to the CCS forum and they will be able to better assist you for answering C++ questions in relation to CCS.  As tools vendors do support C++, but each tool vendor has different ways of supporting it with their run-time libraries.

    Lela

  • I only have knowledge of the TI ARM compiler.   If we are talking about some other ARM compiler, then my comments do not apply.

    The TI ARM compiler supports the full C++ language.  See http://processors.wiki.ti.com/index.php/Overview_of_C%2B%2B_Support_in_TI_Compilers .  

    I can only guess at why adding a pure virtual base class caused the code to break.  Perhaps you define an object which inherits from that base class.  In that case, the compiler generates code to initialize that object at boot time.  This initialization code could have caused a problem of some sort.  Perhaps something timed out.  Like I said, this is just a guess.

    Thanks and regards,

    -George

     

  •  

    The base class does have an object which inheirits from it.  Additionally a pointer to the base class was used to access the object which inherited from the base class.

    Since, in my test case, neither the inheirited class or the accessor class was instantiated or run I do believe the problem must be related to initialization code.

     

    I have removed the base class and everything works well.

    Larry

  • Hi Larry,

    I assume when you talk about a "pure virtual base class" you are not talking about virtual base classes (virtual inheritance, diamond problem, common ancestor), but rather you're talking about an abstract base class with at least one pure virtual function?

    The reason I ask is that I've seen many embedded toolsets bungle virtual inheritance (vtable issues), but abstract base classes ("interface classes") aren't too hard (for the toolset) to get right.  As you indicated, it's pretty common to instantiate objects derived from the base class, and pass around pointers to the base/interface class.

    I don't use CCS, so I don't know what the cause of the problem is, unfortunately.