So my team is moving to C++ away from LabVIEW (which makes me want to bang my head against the wall). I’ve been trying to get some very simple code working (demos). Since I don’t have WindRiver (my team lost the disk), I’m using ucpp to compile through the gccdist. Everything compiles/links fine, so I have a FRC_UserProgram.out , which I ftp up to the cRIO (just reimaged for C++). Then, driver station says Comm works, but claims No Robot Code even after a restart. I’ve verified that the .out file has uploaded successfully to /ni-rt/system .
So any ideas why the driver station still claims that there is no code?
Thanks!
PS: I’ve looked at the .ini files, and it appears that lvrt.out (which I assume means labview runtime) and startup.rtexe (the name of compiled labview code) are still set for startup. Don’t want to toss out a red herring, but could this be it? FRC_ImageVersion.ini has Language=C, so I assume it isn’t and I’m not deploying correctly (though the only file the compiler gives me is the .out file; I’m not exactly sure what I need in this case).
Without the Wind River installation your generic compiler is probably targeting Windows rather than the VxWorks that runs on the cRIO.
Your code on the cRIO is probably starting and immediately dying on the first Windows call.
You can use Netconsole for the cRIO to check the error messages being generated. That gets installed with the FRC Utilities package. Just make sure the cRIO is setup for Netconsole (a choice during the cRIO imaging process).
No, I’m 99% sure it’s targeting cRIO. For one, the build directory is for PPC. I’m using the cross-compiler provided by NI (gccdist) and the very nice ucpp project (https://github.com/nikitakit/ucpp). The makefile is virtually identical to the standard one given by NI.
I would use WindRiver, if I had it. But I wasn’t able to get another copy of the license file. I need to make sure that everything works correctly before build season starts though, so necessity dictates I hack something together.
I second viewing either NetConsole or the serial port output. If you have trouble interpreting it, feel free to post it here and I will do my best to help.
The ucpp project targets the cRIO, and should build code correctly. I have been using that toolchain (under Linux) for years without issues, and with a similar Makefile.
OK. I was able to get NetConsole working after manually changing the default gateway in ni-rt.ini to 10.6.12.4.
More interestingly, it fails to lode the code due to undefined symbol errors. The symbols look like the mangled names of WPILib functions (_Z…WatchdogC1EPi), so i assume that ucpp is not linking in WPILib.
Where is the WPILib file? I assume I could add it to StartupDlls in ni-rt.ini, or change the makefile to run wine ldppc.exe (I too am on linux) or something of the like to statically link them together.
Or have I just missed a step. Again, I haven’t modified the toolchain from the default linux ucpp.
Thanks for your help.
EDIT: Found the WPILib.a file. It looks like it should be linked in (glancing at the makefile). Why am I getting undefined symbol errors then?
Technically WPILib was being linked in. The failure was coming from a mismatch of symbol names between WPILib.a and the NI_FPGA.out binary that exposes symbols to access the FPGA.
Would you care to write up a document describing what you used and how you put it together (potentially including the Makefile you ended up with) so that others on Linux can get a head start?
The ucpp project is just that. It is nicely packaged to make it easy to use.
Universal compiling scripts for FRC
System Requirements:
For Linux: wine, wput
For Windows: MSYSgit or Cygwin
Installation instructions:
- Add the "ucpp/ucpp" folder to your system PATH
- Run the ucpp setup script
$ ucpp setup -t <team-number>
Creating a project
$ ucpp init
Configures the current directory as an FRC C++ project
that deploys code to your team's robot.
The ucpp build system aims to be fully compatible with
development in WindRiver. You can initialize any existing
WindRiver project as a ucpp project, as well as any folder
that contains C++ files.
Building and deploying code
$ ucpp configure
Generates a Makefile for your project
For additional options, run "ucpp configure help"
$ make
Compile the project
$ make deploy
Deploy code to the robot
Note that the main version by nikitakit doesn’t work for me - it calls python2 which is only python on some boxes. Ozzloy added a few commits to detect where python2 was installed and call that through a shell variable, so his fork might work better for many users. He submitted a pull request a long time ago but upstream hasn’t merged them in.
I made some patches to some of the scripts as well, as I was getting syntax errors on my computers (Debian & openSUSE). I have a fork at github (https://github.com/rbmj/ucpp) that has ozzloy’s changes as well as mine until upstream merges them in. I’ve also requested that ozzloy merge my changes into his repo.
Since I forked from ozzloy, my pull request went to him.
The main issue was that the parsing of the team number into an ip address in ucpp-init. Since the method used in ucpp-setup worked, I changed ucpp-init to parse its arguments in the same manner. I also cleaned up the detect python function, as in my case it was outputting the found python twice. Also there was no need to use the output of that function to set ucpp_python_bin, as the variable is globally scoped. Last I included the found python in the settings file so it could be used from other scripts.
Hey: this may seem a bit off topic, but is there somewhere I could get information on compiling code targeting VxWorks on a ppc 603 cpu like you did without windriver? I’m running unix and I’m trying to figure out how to download code to out cRIO without a license for windriver.
I’ve started working on compiling my own cross tools to target the different CPU architecture, but I really don’t know where to start. Any help appreciated!
As stated earlier in the thread, the ucpp project is just that. You don’t even have to compile the compiler - it downloads the windows binaries and runs them through wine. Yes, it’s more difficult, but it’s much easier than managing all of the configuration for the build of the new compiler. And if you’re a windows person, you can either run ucpp through cygwin or download the gccdist provided by NI (https://decibel.ni.com/content/docs/DOC-14237) and run it yourself. Then you grab the latest version of WPILib from FIRSTForge, edit the sample makefile in the gccdist to suit your project, change the makefile to statically link in WPILib, and off you go.
I’ve started working on compiling my own cross tools to target the different CPU architecture, but I really don’t know where to start. Any help appreciated!
Again, if you want a native compiler, more power to you. But the easy way out is already there. Just a few scripts away. If you want more power (I myself wouldn’t completely miss a compiler with c++0x support, but I don’t want to have to worry about a non-standard toolchain screwing up things at competition) feel free to compile your own compiler, just remember that it is the harder way, you may get screwed by it, and few (er?) people will be able to help you.
I already got GCC 4.5.3 compiling on Linux and targeting the cRIO. My patches and build script are here. Thanks to Ross Light for cleaning it up and getting it to run on OSX. It is unsupported, but seems to work well. This also builds my own version of libstdc++v3 that seems to work on the cRIO. It would be nice to integrate this into ucpp at some point.
Hi rbmj. Thanks for the changes to ucpp - I’ve pulled them in.
Right now I’m in college, away from my team, so unfortunately that means I’m somewhat out of the loop on FRC and don’t have a real robot to test code on. I’m probably not the best person to be maintaining ucpp at the moment.
That said, I’m still around online, and I’m still very much interested in seeing ucpp remain usable throughout the next competition. It’s really a shame for teams not to be able to program on Linux when the tools are there, and have been there for quite a while.
byteit101 - do you plan to continue working on ucpp throughout the next year? It will need some updates after kick-off for everything to work with the new versions of WPILib, etc.