Hey,
Can anyone confirm that if I image a cRIO from last year to the new 2010 image with the development environment set to C++ that I will still be able to deploy a .out file using last year’s WPILib? If this is not the case can I use the new cRIO imaging tool with the image .zip from last year to re-apply the 2009 C++ image?
I can’t confirm that, but is there a reason why you can’t just recompile the old code?
EDIT: I believe you can reimage the CRio with the old image, but you must use the 2009 version of the imaging tool.
You probably won’t be able to run 2009 binaries (the .out file) on a 2010 image.
The image includes the WPILib, which has changed significantly in the year since. Your 2009 code will be linked to look for and use the 2009 library, and when it tries to call into WPILib functions, you’ll probably get symbol errors as output.
We weren’t even able to run code compiled for the 2010 v5 image on a 2010 v19 cRio, which we tried by accident by forgetting to recompile the code after we updated everything.
I don’t see any reason why re-imaging the cRio wouldn’t work though. Try that. But remember to re-image it back to 2010 v19 after for development for this year.
No. Any image which changes the FPGA (most do) will need a corresponding change to the development build environment. The version of WPILib used by Windriver must match the FPGA version in the cRIO.
If not, you will get errors at runtime about missing symbols when your .out is loaded (you’ll only see these in debug load, or in console output when deployed).
If this is not the case can I use the new cRIO imaging tool with the image .zip from last year to re-apply the 2009 C++ image?
Yes. More precisely, image with the version of the image that corresponds to the WPIlib your .out file was built against.
If you still have your 2009 source code, you may be better off just recompiling it in the 2010 environment. The API changes from 2009->2010 were minimal. Most teams’ 2009 code should compile and run as-is in the 2010 environment without changes, enabling the use of a single cRIO image version.
Heydowns is exactly correct. To ensure that you don’t build against an incompatible version of the FPGA image, each new version of the FPGA code uses a namespace with a unique identifier. When you load a 2009 program into a 2010 imaged cRIO, you’ll see that all the FPGA (ChipObject library) entry points will pop up as undefined.