I am using VScode extension for PROS to upload code from a macbook to the Cortex. The serial connection is A-to-A from macbook to the Hardware Programming Kit, RJ-11 from the Kit to the Joystick; A-to-A from the Joystick to the Cortex. Using the 7.2 V Vex battery on the Cortex. I can upload code no problem. The program is very simple; turn two motors. The program runs as expected until I unplugged the serial cable from the Cortex which causes the motors to stop. When plug the serial cable back into the Cortex the motors resume turning. Note, this symtom is occuring even when I have just the A-to-A cable connected to the Joystick; the Joystick is not connected to anything on the other side. There are no batteries in the Joystick and the Joystick is turned off. The symptom is the same when using the 393 motors on ports 1 and 10 without motor controllers, and when using the 393 motors on ports 2 and 9 with motor controllers. The symptom is the same when using 269 motors. Is there anything in PROS settings or setup that could be affecting this? Thank you.
Do you have VEXnet keys, you probably want those plugged into the joystick and cortex.
I do have keys but all I am trying to do is turn the motors. I am not trying to control the Cortex remotely via the joystick.
This is the code in opcontrol.c
while (true) {
motorSet(RIGHT_MOTOR, 127);
motorSet(LEFT_MOTOR, -127);
delay(20);
}
To allow “standalone” operation, the PROS kernel would have to indicate to the master processor inside the cortex that it should run that way. I don’t know how PROS does that if at all. There may be a function or some system setting you call. Years ago I also wrote alternate firmware for the cortex, this was the function that enabled that in my code.
/*-----------------------------------------------------------------------------*/
/** @brief Force stand alone operational mode */
/*-----------------------------------------------------------------------------*/
void
vexSpiModeStandalone()
{
// set stand alone mode
// the autonomous task will execute
vexSpiData.txdata.data[3] = 0x01;
}
I’ll ping the PROS developers, but a lot of this knowledge has been lost as almost no one uses cortex any more.
@BennyBoy Thoughts ?
Nobody remaining on the PROS team has any experience with PROS for cortex sadly. I’m sure that somewhere in the kernel 2 archive it performs the action you mentioned, but I am not gonna go looking for it, sorry.
If this issue gets resolved i can add it to some list in our internal docs so we have it for later.
guess I’ll do it for you then.
@mhayes
It may be this.
from API.h
/**
* Enables the Cortex to run the op control task in a standalone mode- no VEXnet connection required.
*
* This function should only be called once in initializeIO()
*/
void standaloneModeEnable();
function is in supervisor.c
// standaloneModeEnable - enable standalone operation
void standaloneModeEnable() {
// set flag in outgoing SPI buffer to enable standlone mode
SV_OUT->flags |= 1;
}
Ok, many thanks, I will try that.
We have about 50 cortex’s at the school I work at in Hong Kong. Our robotics effort got mothballed during covid. I hate to just bin all this stuff. I have had PROS talking to the Cortex way back when and I never had this issue, so it is a real puzzle.
@jpearman, your suggestion seems to be working. Many thanks.
This suggests that the default mode of the Cortex is standaloneMode disabled.
I understand the Cortex is now past tense, but was it intended that if you wanted to run the bot automously, all code would go in auto.c instead of opcontrol.c? I am now thinking if I did not enable standaloneMode, and put that simple test code I shared into auto.c instead of opcontrol.c I would not have seen this problem?
The default was whatever the provider of the programming software decided, at that time VEX only worked with partners to provide programming solutions. RobotC, EasyC and later Robotmesh all supplied software, none (IIRC) were free.
The Purdue team revere engineered the cortex and created PROS somewhere around 2012/2013 (as did I, not working for VEX at that time convex), it was targeted at competition teams which is probably why it was expected to be used with VEXnet keys and a controller.
RobotC had a setting for standalone but not saved with the project, same with EasyC I think.
I believe standalone mode allows the cortex to operate without either a USB connection to the PC/controller or a VEXnet key (it’s amazing how quickly we forget this type of thing despite working with the cortex for several years), it’s nothing really to do with autonomous or driver control modes which, again, are under control of the programming solution which would have code monitoring the competition state.
Many thanks for your detailed replies. The suggestion to use standaloneModeEnable() seems to have fixed the issue I was having.
Thanks again.