I at a competition today, using PROS, and VexNet keeps disconnecting in the middle of the match. My mentor and my RECF rep are telling me that I need to reset my firmware. Is this something that I should worry about with PROS? Can it be done with PROS? Or should I use ROBOTC?
Thanks!
Nope, you can flash master firmware just fine. You’ll want to re-upload your code as well afterwards.
Thanks! What can you say about the reliability of PROS? Having battle-tested it at a competition, it seems to be less stable than ROBOTC, do you agree? The other local team (8926, @bossgivol) which used PROS said that they stopped because it has a habit of randomly disconnecting, and I’m inclined to agree. It’s a real shame too because the PROS development experience is objectively superior, but I have to choose competition consistently over ease-of-development.
We’ve been using PROS for all 7 tournaments that we have attended thus far this season. The only problems we’ve had were when we didn’t include a
wait()
statement in our driver control code, so the PROS kernel background tasks weren’t running properly.
Also, PROS can’t (to to best of my knowledge) directly cause VEXnet issues.
Yeah if your problems were that vexnet kept disconnecting, this absolutely has nothing to do with PROS. Whether you use pros or robotc vexnet is handled by the master firmware.
It’s impossible for PROS to cause disconnects.
This is the first I’m hearing of PROS being the common denominator between two teams having VEXnet drop outs. Can you share your code (either here or email pros_development at cs.purdue.edu)?
Sure. All my code is hosted on github. As for 8926, you would have to reach out to them, they are not hosting their code online
As @Barin mentioned, you must have a delay statement in any infinite loop (like your opcontrol). Without the delay, you will starve the scheduler and prevent other tasks from running. A small delay like
delay(10);
is sufficient.
Hrm. This is interesting to me. The tasks in PROS, are they ‘native’, or are they emulated? By native, I mean that the code which ensures the connection is maintained runs in the structure that PROS calls a task? It’s always hard to tell with compiled binaries, I know, but does the bootloader of the cortex support tasks?
I was going to ask this same question. Now that I know it’s possible, how do you flash master firmware from within Atom/PROS? I have no problem uploading code using PROS. At our last competition we had to redo the firmware onsite. As we’ve got all Macs and PROS aligns with the programming classes much better, I’m trying to switch over and not have to cart along one of the junky Windows laptops just to update firmware. It’s probably really obvious how to flash master firmware, but I’ve been searching for a long time without finding it. So I’d really appreciate a pointer.
Thanks,
Chris
@callen The currently is no support to do it in Atom, because of the reason that updating firmware is beyond ROBOTC, PROS or EasyC. From what I know the only way to update is with ROBOTC’s updater.
Vex has a firmware update utility that allows you to update both the remote and cortex.
Yep, like @Tylennis said, use the official master firmware updater provided by vex
https://www.vexrobotics.com/vexedr/resources/firmware
Thanks. I guess I have to keep Windows running on at least one computer, then. Too bad. I was hopeful after using VEXosUtility on a Mac and having it work so much better for VEX IQ than updating through RobotC. Hopefully they’ll extend VEXosUtility or make something new for Cortex.
I’m really confused about the earliest posts, then. The OP asked a few variants on the question, so the “nope” in the “answer” is unclear, but the statement that the person using PROS and asking if he can deal with the firmware in PROS “can flash master firmware just fine” seems to be incorrect as opposed to answering the OP. These last three responses are much clearer. Thank you.
Thanks for your time,
Chris
The master firmware gets updated infrequently enough that you’ll probably be just fine without keeping a Windows machine around.
With that said, it probably wouldn’t be a bad idea to keep a Windows machine around in case of firmware corruption or something.