OpenVex  0.5.0
Functions
Controller Status

Functions

void controller_init (void)
 
unsigned char controller_in_autonomous_mode (void)
 
void controller_end_autonomous_mode (void)
 
void controller_begin_autonomous_mode (void)
 
void controller_submit_data (unsigned char wait)
 
void controller_print_version (void)
 

Detailed Description

Function Documentation

◆ controller_begin_autonomous_mode()

void controller_begin_autonomous_mode ( void  )

Signal controller to begin autonomous mode. In autonomous mode, the controller ignores RC input and allows the user program to operate without checking for it.

Note: The orange light on the Vex controller blinks more rapidly in this mode than in remote control (RC) mode.

◆ controller_end_autonomous_mode()

void controller_end_autonomous_mode ( void  )

Signal master processor to end autonomous mode and return to remote control mode.

◆ controller_in_autonomous_mode()

unsigned char controller_in_autonomous_mode ( void  )

Determine current operation mode of the controller.

Returns
TRUE if the controller is in autonomous mode, FALSE if not.

◆ controller_init()

void controller_init ( void  )

Initialize Vex hardware. Must be called before accessing any controller ports.

◆ controller_print_version()

void controller_print_version ( void  )

Print the firmware version(s) currently on the controller.

◆ controller_submit_data()

void controller_submit_data ( unsigned char  wait)

Buffer PWM data, etc. to be sent to the motors/servos.

This function must be called following other controller_*() and pwm_*() functions in order to make the updates take effect. This allows multiple PWMs to be altered using separate pwm_write() calls without actually changing the motor speeds at separate times. Instead, pwm_write() places changes in the buffer, and all changes are submitted together by controller_submit_data(), so that motor speeds can all be changed (almost) simultaneously.

This can also reduce load on the PIC user processor caused by buffer management for each packet sent. Programmers are encouraged to make multiple changes via pwm_write() and controller_*() functions before each expensive controller_submit_data() call.

Parameters
waitOne of the manifest constants WAIT or NO_WAIT. Specifies whether or not to wait for data to be submitted before returning to the caller.

PIC controllers:

If WAIT is used, controller_submit_data() will not return until the master processor has picked up the packet. This could mean up to a 18.5 ms delay before returning to the caller, during which no other code (except interrupt handlers) can execute. Generally, this should only be done if the next statement after controller_submit_data() should not be executed until the master processor has received the current command.

If NO_WAIT, controller_submit_data() returns immediately, and the data will be picked up by the master processor at an unknown time within the next 18.5 ms. This is the preferred method if it isn't critical when the submitted data takes effect, since it avoids burning up to 18.5 ms of CPU time that could be used for useful work.

Example: If you want a delay loop to begin after motors have actually started, to guarantee that the motors run for the full specified delay period:

pwm_write(LEFT_DRIVE_PORT, 50);
pwm_write(RIGHT_DRIVE_PORT, -50);
delay_msec(250);

Note that in many applications, it wouldn't matter much if the motors run for 231.5 ms instead of 250 ms, so NO_WAIT may be perfectly reasonable in the above example.