Coding in C++ in Creator 2.2

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am relatively new to Psoc5 and Creator and am re-acquainting myself with C++.  I am having difficulties getting a particular program to build.  I know that Creator is C based but that one can also "force" it to recognize and compile C++ code.  The program is extremely simple:

   

#include <iostream>
using namespace std;

int GetFibNumber(int FibIndex)
{
    if (FibIndex < 2)
        return FibIndex;
    else
        return GetFibNumber(FibIndex - 1) + GetFibNumber(FibIndex - 2);
}

int main()
{
    cout << "Enter 0-based index of desired Fibonacci Number: ";
    int Index = 0;
    cin >> Index;
   
    cout << "Fibonacci number is: " << GetFibNumber(Index) << endl;
    return 0;
}

   

In the Build Settings associated with all .c files I have added "-x c++" as a custom flag in the command line.  The errors I get when I build this is:

   

prj.M0120: undefined symbol `Reset' referenced in expression

   

prj.M0120: The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

   

Any ideas what I'm missing?  Thanks.

0 Likes
12 Replies
Anonymous
Not applicable

So I've been digging and reading forum posts...

   

One setting that I had wrong was with the toolchain.  I was not using the ARM GCC Generic toolchain but I fixed that.  Then I discovered that the path was incorrect...I fixed that.

   

Now I'm getting the following:

   

prj.M0120: The command 'arm-none-eabi-as.exe' failed with exit code '1'.

   

Still hoping for some helpful insights

0 Likes
Anonymous
Not applicable
0 Likes
Anonymous
Not applicable

 Good reading    

0 Likes
Anonymous
Not applicable

Yeah, I read that article earlier and it helped me eliminate a ton of build errors but alas two remain:

   

undefined symbol `Reset' referenced in expression

   

The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

   

I tried specifying the generic toolchain ARM Generic and also ARM GCC 4.4.1 with identical results.

   

I'm about to abandon efforts to force C++ in Creator and conform to C, although I still believe C++ is a better overall tool.  The upside is that eventually I'll know both!

0 Likes
Anonymous
Not applicable
        OK, I would tell you a uncertain method that success at AVR Studio but no good for PSoC1 Designer, The Method is Delete "gcc.exe" and rename "g++.exe" to "gcc.exe" I have not do on Creator yet. This is unsure way. I don't know what will happen. Anyway, I know clearly, C++ for PSoC has dificult problem. PSoC's peripheral module was build by conventional C, you know. When you want to programming by c++, you have to make wrapping class for those all user modules. PSoC is the most objective MCU ever, I agree that need objective language for PSoC. We have to wait when the Cypress decide ganna change and make C++ for PSoC. How do you think?   
0 Likes
Anonymous
Not applicable
        Recently, I think The PSoC has the objective method already itself. A kinda capsulation and a kinda Inheritance was practically established already. Do you know custom user module? That is practically objective method. You could be know when use this.   
0 Likes
Anonymous
Not applicable

I have had success with using C++ with PSoC Creator (I am the author of that article on cladlab that is linked above).

   

 

   

Hmmm, I see you are using <iostream>. This defines standard in and out stream objects, and can include other headers also. It might be that this is too much for an embedded design (an overflowing memory). I do remember trying to use the << stream notation before and having RAM overflows, although I can't remember if it was iostream or not that caused the issue.

   

 

   

Other than that, you mention "failed with exit code 1". This is normally the generic error shown on the "notice list". If you switch to the output window, you might be able to glean more about the error, as you will see compiler output messages. Have a look there and post anything that gives more information on what is wrong.

0 Likes
antu_285091
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted
        I did a brief test and got some toy C++ to work without any problems. I added the "-x c++" to the overall build properties as opposed to each .cc file. The compiler warns about it for the .c files, but I can live with that for now. Has anyone looked into using a proper Makefile for PSoC builds? It looks like most of the work happens through command-line tools, and those will work nicely in a Makefile. If they're doing important things through DLLs, that's more difficult. I've got a bunch of C++ code originally written for STM32 that I'd like to port to PSoC (for the analog goodness). The data model stuff will work fine, but anything that touches a peripheral is more complicated because of Cypress' function-based code generation. The PSoC idea is very forward looking, but locking out C++ seems very unfortunate. It'd be great if they opened up an API to the code generation, but I won't hold my breath.   
0 Likes
Anonymous
Not applicable

 Thats interesting, that you got "-x c++" to work in the global build settings, since that would make every file be compiled as C++, and as far as I'm aware, the Cypress-generated peripheral code does not have C++ header guards (the #ifdef __cplusplus extern C{ } #endif directive).

   

 

   

So it worked even for these files, and just produced warnings? I will have to make a test project myself sometime and see how far you can take this. Including "-x c++" just once in the build settings could have many possible advantages, including making it simpler (as opposed to entering in "-x c++" in every C++ files settings, which if moved to a different file location are lost), and also may mean that you can include some of the other C++ stuff that seems to be missing (__cxa_guard_aquire/__cxa_guard_release e.t.c).

0 Likes
antu_285091
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

 gbmhunter:

   

The Cypress generated code doesn't have the #ifdef __cplusplus stuff, but that isn't necessary because GCC realizes the the .c files are straight C. Of course, if you include the generated .h files into a C++ file, you'll need to wrap them in extern "C" {...};

   

Each .c file with "-x c++" generates a single warning from GCC saying that option doesn't apply. I'd much prefer a totally clean build, but those warnings are fairly easy to ignore. Having to add "-x c++" to each .cc file seems more onerous, IMO. The entire problem would go away if they used GNU make.

   

Related to the OP's use of <iostream>, is there any way of getting text output off the chip and into the debugger console? I think this is called "semi-hosting" in the ARM world.

0 Likes
Anonymous
Not applicable
        Hi Everyone, Thanks gbmhunter-san for your good teaching. I do it on PSoC5 and Build and programming device is accomplished. Only "-x c++" and "extern "C" {...};" was needed. Where have I been huh. "extern "C" {...};" was need strictly for C source include "#include". However, Work of PSoC is seems sightly odd. It seems Memory area is refreshing at random. I have to continue investigation of problems more. Thank you   
0 Likes
Anonymous
Not applicable

andyTurk:

   

 

   

Strange, because "-x c++" is meant to force the compiler to treat any file as a C++ file, no matter the extension. So if you added it to the global build settings, I would of thought it would try to compile the PSoC peripheral API code as C++.

   

 

   

So maybe is DOES compile as C++? IIRC, C++ was desinged so that it could compile C code without any problems. I know there are issues such as name mangling (which is what those guards are for), but maybe this is not relevant in this case?

0 Likes