This was inspired by complaints about the needed reboot after code download to the cRIO
What I would basically like is a button on the driver station, similar to the reboot button, that kills and reloads user code on the cRIO. From what I know about the system, I don’t think this would be too hard. User programs run in their own task, and this task is loaded as a default library on boot. To do this, the simplest thing would just be kill the user program task and reload it from flash. Don’t think it would be too hard unless there is some aspect of the system I’m missing
This would be really helpful for downloading code since the reboot time is the most annoying thing when downloading for me. according to NetConsole, the time for the actual user program to load relative to the rest of the system boot is minimal, in most situations less than a full IFI boot. A simple reset of the task after download would save much time in the pits and for programming in general (as well as many “can we run it yet?” questions. Why can’t they learn the RSL codes?)
Well, it would be a good idea if you only had the main thread (task) running.
There are other threads running in the background (ie compressor, FRCCOMMS, vision, etc)
These tasks take up RAM.
And if the main task doesn’t properly deallocate all of its resources, then when it is killed these objects could still remain in RAM.
Rebooting the cRio clears all of the RAM, and is an option that doesn’t have to have properly written code.
With most of the other team’s code that I have helped clean up, memory management was the last concern.
Its probably best for the developers of the Control System, to keep the reset as it is (eventhough it does take a while to come back up) instead of trying to debug the problems of poor memory management.
As far as rebooting when deploying code, Netbeans for Java has the squawk VM reboot the robot when the code has been uploaded. It still takes the same time as a powercycle boot, but it seems faster because you don’t have to manually reset the power (or push the reset button, or reboot from the DS).
Well most of the background tasks are persistent ones (frcnetworkcommunication, frcvision, pcvideoserver, CAN bridge), and they would never have a reason to terminate other than a crash. For the rest of it a script can be setup that iterates through the task listing and kills the unknown or usercode instance specific tasks.
Also on our bot we generally use netconsole for a reboot since it means we don’t have to wait for the camera to boot (CAN code seems to die if the camera isn’t completely booted).