Quote:
Originally Posted by carrud
This being a "single-mode OS" seems to be the underlying force behind this happening. At least in some cases.
|
There is a fundamental misunderstanding in this thread about what "deploying" really means. The transfer is from an FTP client (Windoze) to an FTP server (the robot). The file you are transferring is NOT a fully linked executable. It is code to be dynamically linked and loaded to the VxWorks/FIRST/WPI infrastructure on the robot. So every unknown symbol in the deployed .out file must be satisfied in the text and data segments of the VxWorks/FIRST/WPI/NI code already on the robot (put there when we image the cRIO). This dynamic linking loader is a single pass algorithm, not a dual pass linker like the one we use when combining multiple objects on our development station (where the WindRiver 3.3 is running).
So how does one make sure their code will load and run (2 distinctly different issues)? Most FIRST programmers simply deploy and debug using print/log/smartconsole output. But without using the debugging interface to the robot, you will miss messages about the unresolved symbols and/or tasks getting suspended for various violations (memory access, divide by zero etc). Instead create a target server and load and run your code using the debugging tools and you will see these errors and fix them. FIRST has a tutorial that covers this procedure. NetConsole MIGHT catch them depending on how badly the errors cripple the OS on the robot.
http://wpilib.screenstepslive.com/s/...-robot-program
Many of you might think this is a lame setup. But I remind you this exactly how adding code to the Linux kernel (and many other operating systems) works. WindRiver and VxWorks are not unusual in this respect.
HTH