I am curious who is going the C++ route and whether you are encountering the problems we are having.
It has been a daily uphill battle with little satisfaction.
How is your team doing? Is a collaborative group in order?
Especially interested in your progress in getting your code to load into the unit.
WC 
I have a robot running on C++ code.
Any point in particular where it all goes south?
ok- here goes
we are able to get the default code up and running ok- wireless too. But for some reason the cRIO isn’t taking any new code we try to load into it. For that matter it won’t take a reload of the default either. I am sure it is a procedural thing but we haven’t been able to figure it out. I am not the code guy so I can’t help them too much.
It would be nice to actually be able to start playing with some code sequences…
Have you done a format with the FRC Crio Imaging tool? There is a radio button that you have to tick to switch to C++ from labview.
Windriver setup is a little tedious. I can’t remember how long it took to understand it but here is what I can remember.
Hopefully you installed Windriver into the default location using the default workspace. Assuming that, go to C:\Windriver\docs\extensions\FRC and look at the C Programming Guide for FRC. It is definitely not finished but it gets updated when updates to C++ are released.
Starting at page 85 is the setup to connect to the cRIO and use debug etc. You should be able to open a program from the File/New/Example/VxWorks Downloadable Kernel module Sample Project like Iterative Robot Demo Main Program and then compile it with project/Build All.
i can’t remember where the documentation is to set up the FIRST Downloader but go to Windrivers toolbar and go to Window/Preferences. In the list on the left select FIRST Downloader Preferences. Enter your team number and check the path to the file to download to the cRIO. My path is:
C:\Windriver\workspace\Iterativedemo\PPC603gnu\IterativeDemo\Debug\IterativeDemo.out
This is the compiler output file targeted for the PowerPC in the cRIO. If this path is right, when you go to the FIRST tab on the toolbar and select Download the file will be transferred to the cRIO solid state drive. You have to make sure the cRIO is configured for C++ with the Imaging tool and then reboot and the cRIO should load and run the program. If you reconfigure for Labview and back to C++ this file will load and run again. It is not written over by Labview output. You can remone it with Undeploy in the FIRST pulldown.
Hope this helps some.
Usually when something like that happens to me, it’s because I’m editing the wrong files or uploading the wrong files.
*Make sure that the files you’re editing in the editor are the same as the ones the linker/compiler is using
*Make sure you’re uploading the latest output from the compiler to the robot. Too many times in past years I’ve uploaded the same .hex file to the robot over and over, and wondering why things weren’t changing. I don’t know what the binary compiler output for the Crio looks like, but verify that the date modifieds on all the files you send to the robot are recent.
We have 7 programmers working in WindRiver! 
Great Success!
If you need help with something i’d be glad to help.
Im on here a decent amount and i’m usually on the IRC chat too.
Have you read all of the configuration documentation for it?
there’s about 2 hours of work worth of setting everything up.
Does WindRver connect to the cRIO device as a Remote System?
Wayne,
We have a proto base up and running in C++, and we’ve been able to download code into FLASH (which stays there when the robot is powered off) and also run code from RAM in debug mode. So, I can tell you it is possible 
I’m amazed though by how difficult the process is. The sheer number of things that need to be configured (and worse, the number of other settings that need to be left alone) is daunting. This is one particular reason that I feel the choice of Eclipse/Workbench for C++ development was a very poor one. It has ALL the bells and whistles and tools that a serious embedded software engineer needs, but most of this is unnecessary and overwhelming to high school students. I’m currently experimenting with a simpler development setup that hides a lot of the complexity; if I get something working there I’ll release it for everyone to use.
We somehow ran into a problem last night where the compiled binary that was being downloaded for debugging into RAM was not the same one that got saved in FLASH when “deployed”. We couldn’t figure out why our robot didn’t work right when we ran it from FLASH. Turns out there’s 2 separate path settings in 2 different places in the IDE, and they were somehow each pointing to a different binary. That took a couple of experienced embedded software people a good half hour to find and solve. I’m not sure an average high school kid would have ever sorted that out.
The documentation is almost too extensive. It’s hard to find what you need when it’s buried in hundreds of pages of docs. Also, the C Programmer’s Guide is pretty good for getting you going, but I dislike the order it’s presented in. The stuff that you need to do first to get a project up and running is presented at the end of the document, somewhere around page 85. I find myself greatly missing the IFI docs, which were only 20 pages long or so and yet seemed to cover most of what you needed in clear, concise language.
Anyway, if you’re struggling I’d recommend having your software people post questions here on CD - there’s a contingent of us around slowly getting the C++ stuff to work that can probably help you out.
Dave -
I’d be very interested in hearing your ideas about making a more streamlined interface. I agree that the environment can be pretty daunting for programmers without that embedded programming experience.
Maybe there might be some programmers with some good eclipse plug-in experience who could help out…
Also, please feel free to send any comments about the documentation that you feel would make it more understandable. It is a huge amount of stuff and I always worry about the amount of time it will take people to find their way around it.
Thanks for helping
Brad
I was also dismayed at the complexity of the setup. Once you get over that hill, however, I haven’t had too many problems.
If you’re not familiar with C++ (or if you are but are unfamiliar with object-oriented programming), I’d check out a tutorial like www.learncpp.com. I remember had a bit of trouble wrapping my head around the new system at first. If you want to code more procedurally, WPI is developing a C-style wrapper for WPILib, which I don’t believe is out yet.
Another great help is the C/C++ Programming Reference. And to echo Dave, a lot of us on CD are all pushing through this together, so here is a great place to post questions.
Also, in the next version we’re trying to push out there will be a complete set of C functions to program the robot for those who don’t want to try C++ on top of all the other new stuff. Although, I’d suggest giving C++ (at least) a quick try first since the interface is somewhat richer once you get the hang of it.
I’d expect that next version next week sometime.
We had similar problems in loading code to the cRIO, but we figured it out and we are testing out different programs.
It took us a while to get up-to-speed with Wind River at first too, but after doing so we find it lots more fun to use than either MPLAB or LabVIEW. To me the primary hurdle is learning all the buttons and settings you need to get WR running. After you do that, learning to use C++, even if you’ve only programmed in C, is not difficult to do because you’ve got lots of example code and the WPILib to follow and learn from.
You do need to watch out, when working in RAM, to undeploy code that you’ve loaded into FLASH.
Once you get the hang of it, the turn-around time in developing code with WR and C++ is very fast.
I think learning WR is a worthwhile experience too. I had never used WR myself before. But I now work in an environment with lots of coders of embedded software – when I look around at what they use – Eclipse.
Hi All,
I am getting the Windriver “Open Workspace” error about “filesystem is not lockable”. Windriver was installed by the Administrator ID and made available for use by Power Users. When the user starts Windriver as Admin, no problems.
When a Power User starts Windriver, this error pops up and clicking on the “Yes” (to continue opening the workspace) does nothing.
I tried clearing the Read Only attribute to C:\windriver and all its folders/files but no change.
Any ideas? Help!
TIA
I, like Dave, believe the IDE setup documentation should be at the beginning of the programmers guide. Or in a separate file with lots of bold font screaming “DO THIS FIRST!”
WindRiver takes a lot of getting used too… It’s Team 1241’s first time using the environment (including mentor’s) so it took us a while to get familiarized with everything, but with some help from our neighboring teams (thanks 1114 and 1503) we have made headway with coding.
With the Iterative Robot code, when we try to build (after including all the WPILib Files and others), we get errors only when WindRiver reaches the last file (IterativeRobot.out)… The errors however, are located on lines which either have “{” or “//”… but none of the errors occur on lines with any code on them, wondering if any other teams have encountered a similar problem (and any suggestions on how to get around it)… this occurs in many many files (ie. Compressor.cpp, Counter.cpp, etc) and often occurs on a line in the middle of a commented section (from file "Counter.cpp):
/**
- Set the upsource for the counter as a digital input channel.
- The slot will be the default digital module slot. (<— error on this line)
*/
And this is using on WPI Library files and the IterativeDemo base code in WindRiver
That typically means the error actually occurred prior to the line pointed out.
The line quoted is just how far the compiler got before it figured out something wasn’t quite right.
Hello from TEAM 141, West Ottawa High School the WOBOT. We have our test robot up and running using the Wind River C++ development tools. We used the base example code and have been able to modify and download into our robot. We are working on a simplified setup document to help our team members work in teams to develop new functions.
This week we are testing and documenting all the sensors we have used in our last 3 robots. We want to have a library of sensor we can use and example code for each sensor.
David Barr
I too cannot get the Iterative Robot to build. Anyone know the answer?
yarb, are you getting errors saying “Multiple Definitions” of counters, etc?..
I’m not exactly sure how these files have multiple definitions, but our errors are all based around multiple definitions of various operations (counterinit for example)… funny thing is its a default code, no modifications this time. Only thing we haven’t tried yet is re-installing the software.