New tool for C++ Programming for old cRIOs

[mikets]

Since the season is over and school has ended, we are starting to look into reviving all our old robots with the cRIO controllers. We are very happy to find your tool chain for Eclipse. Thank you very much.
In season 2015, we switched from C++ to Java but we did follow the instructions to install Eclipse with C++ so that the environment can handle both Java and C++. Now it's the real test if that works.
We followed your instructions installing the tools chain, configuration the team number and all that. We created a new C++ project. Drag our Rebound Rumble code to the src folder within Eclipse. Everything seems working smoothly. However, when it comes to time for compiling the project, it gave us some trouble. It looks like Eclipse doesn't know where to find the gcc compiler:

00:06:20 **** Build of configuration cRIODebug for project ReboundRumble ****
"C:\\Program Files (x86)\\FRC_Toolchain\\mingw\\bin\\mingw32-make.exe" all 
'Building file: ../src/DashboardDataFormat.cpp'
'Invoking: Thunder cRIO Tools C++ Compiler'
powerpc-wrs-vxworks-g++ -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -IC:\Users\Michael\Projects\Frc\2015\code\ReboundRumble\include -I"C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\/../include/WPILib" -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=603 -mstrict-align -mlongcall -MMD -MP -MF"src/DashboardDataFormat.d" -MT"src/DashboardDataFormat.d" -o "src/DashboardDataFormat.o" "../src/DashboardDataFormat.cpp"
'powerpc-wrs-vxworks-g++' is not recognized as an internal or external command,
operable program or batch file.
mingw32-make: *** [src/DashboardDataFormat.o] Error 1

00:06:21 Build Finished (took 145ms)

I found the gcc compiler. It's in C:\Program Files (x86)\FRC_Toolchain\mingw\bin. So how to I tell Eclipse where to find it? I went through the maze of Eclipse Preferences and can't seem to find any tool path that I can configure.
Also, the code currently has lots of red X's. It seems the #include WPILib.h line couldn't be resolved. I must have missed a step to "import wpilib". I thought it's part of the tool chain install but may be not. Please advise how to fix this.
Thank you very much for putting this out.

[mikets]

Originally Posted by mikets

Also, the code currently has lots of red X's. It seems the #include WPILib.h line couldn't be resolved. I must have missed a step to "import wpilib". I thought it's part of the tool chain install but may be not. Please advise how to fix this.

I think I figured out this particular problem. At the beginning of the 2015 season, when installing the software, the instructions advised to uninstall the old NI software including WindRiver. I found the Eclipse path still pointing to ${WIND_BASE}....\WPILib. Interestingly, even WindRiver was uninstalled, the c:\WindRiver\WPILib folder still exists. I supposed that's part of the FRCUpdate so WindRiver uninstall won't touch it. In any case, I extracted the WPILib header files and dragged those into the project include folder. That seems to fix the problem. Now I just need to tell Eclipse where to find g++. The code still has lots of red X's now complaining about some pure functions have not been implemented. So I am still missing something but I am ignoring this for now. Let's fix one thing at a time.

[mikets]

Regarding the g++ not found issue, I suspect it has something to do with the Eclipse perspective. I clicked Window->Open Perspective->Other to open the perspective dialog. It showed the "C/C++ {default}" perspective. Since it said it's the default, I think I am good. In any case, just for good measure, I selected it and click OK anyway. But it didn't do anything. Still got the same g++ not found error.

[tomy]

I'm having a major error when I go to deploy the code. I get an error stating it cannot find the .out file. I looked under the cRIODebug and it didn't create the .out when we built the code. Any suggestions.

[heydowns]

Originally Posted by heydowns

Also whilst I am here - we have not forgotten about the "space in workspace path" problem noted earlier in the thread. Just have not had time yet to address it.

Just a quick note to follow up on this issue. We've released a new version of the plug-ins which will resolve the "spaces in your project path" issue noted earlier in the thread. If you were encountering this issue and did not work around it, you will want to grab the update and then re-create your project by running the new project template again. Unfortunately the fix was with the project creation wizard, so recreating a project is the only easy way to fix it.
To get the new version, you can just "check for updates" in eclipse, assuming you have the update site installed and enabled, which you likely will if you have the older version of the plug-in.

[mandrews281]

I'm seeing an error on some of our systems (Lenovo W540 running Windows 7) with the post-build step. The tclsh program is crashing when I run the build runs the following step:

' '
C:/Program Files (x86)/FRC_Toolchain/mingw/bin/mingw32-make --no-print-directory post-build
powerpc-wrs-vxworks-nm "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so" | tclsh "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\/host/resource/hutils/tcl/munch.tcl" -c ppc | sed "s/extern void\(.*\);/extern void \1 __attribute__((externally_visible));/" > "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.c" && powerpc-wrs-vxworks-gcc -c "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.c" -o ctdt.o -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -fmessage-length=0 -mcpu=603 -mstrict-align -mlongcall && powerpc-wrs-vxworks-g++ "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.o" "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so" -o "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so.out" -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -fmessage-length=0 -mcpu=603 -mstrict-align -mlongcall -r -Wl,-X -static -T "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\share\ldscripts\dkm.ld" && powerpc-wrs-vxworks-stripsyms.bat "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so.out" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\lib\libstdc++.a" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\lib\libsupc++.a" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\..\lib\gcc\powerpc-wrs-vxworks\4.8.2\libgcc.a"
' '

The ctdt.c file is not getting created. Has anyone else seen this? Any ideas for fixing the problem?

Thanks for the great good you have done porting the old toolchain the eclipse.

[heydowns]

Hello,

Originally Posted by mandrews281

I'm seeing an error on some of our systems (Lenovo W540 running Windows 7) with the post-build step. The tclsh program is crashing when I run the build runs the following step:

' '
C:/Program Files (x86)/FRC_Toolchain/mingw/bin/mingw32-make --no-print-directory post-build
powerpc-wrs-vxworks-nm "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so" | tclsh "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\/host/resource/hutils/tcl/munch.tcl" -c ppc | sed "s/extern void\(.*\);/extern void \1 __attribute__((externally_visible));/" > "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.c" && powerpc-wrs-vxworks-gcc -c "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.c" -o ctdt.o -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -fmessage-length=0 -mcpu=603 -mstrict-align -mlongcall && powerpc-wrs-vxworks-g++ "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/ctdt.o" "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so" -o "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so.out" -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -fmessage-length=0 -mcpu=603 -mstrict-align -mlongcall -r -Wl,-X -static -T "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\share\ldscripts\dkm.ld" && powerpc-wrs-vxworks-stripsyms.bat "C:/Users/entech/Entech2013RobotPele/hooks2/cRIODebug/hooks2.so.out" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\lib\libstdc++.a" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\lib\libsupc++.a" "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\\..\..\lib\gcc\powerpc-wrs-vxworks\4.8.2\libgcc.a"
' '

The ctdt.c file is not getting created. Has anyone else seen this? Any ideas for fixing the problem?

Is there any additional output? The above is the command set that runs during linking, but I don't see any output from the execution of it. If you have that, it may help me point you to what is going on.

I don't have any reason to believe this is your specific problem, but the vast majority of issues I have had people tell me they encountered has to do with odd additions to the PATH environment setting in Eclipse. For other readers of this thread, if you are having seemingly random issues and have installed any other Eclipse plugins (outside of the WPI FRC ones), check the PATH setting inside of Eclipse by right clicking your Thunder cRIO Tools-based project, choose Properties, expand C/C++ Build on left, then pick Build Variables. If you have any variables set, especially PATH, you may wish to try deleting them (make a copy elsewhere first!) and re-running your build.

Thanks for the great good you have done porting the old toolchain the eclipse.

You are welcome - I am glad you are finding it useful.

[Alan Anderson]

tclsh "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\/host/resource/hutils/tcl/munch.tcl" -c ppc

The transition from backslashes to forward slashes after the wind_base directory looks confusing to me. Is it similarly confusing to the tcl interpreter?

[heydowns]

Originally Posted by Alan Anderson

tclsh "C:\Program Files (x86)\FRC_Toolchain\mingw\powerpc-wrs-vxworks\wind_base\/host/resource/hutils/tcl/munch.tcl" -c ppc

The transition from backslashes to forward slashes after the wind_base directory looks confusing to me. Is it similarly confusing to the tcl interpreter?

It is confusing, I agree; something I can look at cleaning out in a future version. But the tcl interpreter that is invoked deals with it just fine on the many installations I have tested with.