Vex SW Architecture

[yogibear]

I would like to understand the SW architecture that is used on the Vex system. I have found 2 sources of information so far, but I am hoping for more detail. I want to understand any timing constraints so I can write code that can actually executed in the available time. IFI help folks could only suggest that I read the PIC documentation, even though their implementation is what I actually concerned with.

What is actually happening in the background when I have encoders and an ultrasonic range finder that generate interrupts?

I've been told that if I use PrintToScreen statements to check the timing of code, I will actually alter the time to execute. Sound a bit like Heizenberg's Uncertainty to me.

Thanks for any and all help,
Pat

The WPILib documentation says
"The user to master communication happens periodically over a serial bus connecting the two processors. Every 26ms for FRC or 14ms for VEX the master processor sends the current state of the OI to the user processor and receives the current speeds for the PWM outputs to drive the motors. If this communication does not happen, the master processor will stop the user processor resulting in the flashing red code error light."

The following code is found in the default main.c routine, which is not necessarily indicitive of how fast custom user code can run.
if (statusflag.NEW_SPI_DATA) /* 18.5ms loop area */
{ /* I'm slow! I only execute every 18.5ms because */
/* that's how fast the Master uP gives me data. */
Process_Data_From_Master_uP(); /* You edit this in user_routines.c */

[charrisTTI]

Originally Posted by yogibear

I would like to understand the SW architecture that is used on the Vex system. I have found 2 sources of information so far, but I am hoping for more detail. I want to understand any timing constraints so I can write code that can actually executed in the available time. IFI help folks could only suggest that I read the PIC documentation, even though their implementation is what I actually concerned with.

What is actually happening in the background when I have encoders and an ultrasonic range finder that generate interrupts?

I've been told that if I use PrintToScreen statements to check the timing of code, I will actually alter the time to execute. Sound a bit like Heizenberg's Uncertainty to me.

Thanks for any and all help,
Pat

The WPILib documentation says
"The user to master communication happens periodically over a serial bus connecting the two processors. Every 26ms for FRC or 14ms for VEX the master processor sends the current state of the OI to the user processor and receives the current speeds for the PWM outputs to drive the motors. If this communication does not happen, the master processor will stop the user processor resulting in the flashing red code error light."

The following code is found in the default main.c routine, which is not necessarily indicitive of how fast custom user code can run.
if (statusflag.NEW_SPI_DATA) /* 18.5ms loop area */
{ /* I'm slow! I only execute every 18.5ms because */
/* that's how fast the Master uP gives me data. */
Process_Data_From_Master_uP(); /* You edit this in user_routines.c */

Interrupts provide a way to signal the processor to stop what it is currently doing and run a special piece of code to handle the interrupt. When the processing of the interrupt is complete the processor returns to running the original program exactly where it left off. An interrupt provides a way to immediately handle an event rather than polling for changes in the state of an input within the main program. Interrupts allow us to be sure that we do not miss events (with some caveats) or more accurately measure the timing of events. For an encoder, the interrupt is used to increment the variable used to store the number of steps. In a polling loop, steps could be missed while the processor is doing something else resulting in an inaccuracy in the measurement. For the ultrasonic range finder, we want to measure the time between when the transmitter fires and the receiver detects the reflection. The timer is started when the transmitter is fired. The timer is stopped when the interrupt occurs. The use of the interrupt allows for more precise measurement of the time. In a polling loop there would be significantly more uncertainty in the measurement of the time. We might even miss the signal altogether if the signal from the receiver is shorter than duration of the loop. Interrupts are a powerful feature which must be used carefully. Interrupt service routines should be kept as short as possible. Do only the processing that is absolutely required. Let the main program loop do as much of the work as possible.

[yogibear]

Originally Posted by charrisTTI

Interrupts provide a way to signal the processor to stop what it is currently doing and run a special piece of code to handle the interrupt. When the processing of the interrupt is complete the processor returns to running the original program exactly where it left off. An interrupt provides a way to immediately handle an event rather than polling for changes in the state of an input within the main program. Interrupts allow us to be sure that we do not miss events (with some caveats) or more accurately measure the timing of events. For an encoder, the interrupt is used to increment the variable used to store the number of steps. In a polling loop, steps could be missed while the processor is doing something else resulting in an inaccuracy in the measurement. For the ultrasonic range finder, we want to measure the time between when the transmitter fires and the receiver detects the reflection. The timer is started when the transmitter is fired. The timer is stopped when the interrupt occurs. The use of the interrupt allows for more precise measurement of the time. In a polling loop there would be significantly more uncertainty in the measurement of the time. We might even miss the signal altogether if the signal from the receiver is shorter than duration of the loop. Interrupts are a powerful feature which must be used carefully. Interrupt service routines should be kept as short as possible. Do only the processing that is absolutely required. Let the main program loop do as much of the work as possible.

Thanks! That is terrific information for me that I was unaware of. Given what you said, how can I then quantify the effect of sensors that are interrupt driven, such as the encoders and ultrasonic range finder?

I still feel like I'm missing some key understanding of the software and timing, and that until I understand this, I won't be able to write code that effectively uses the available resources. If anyone has additional information, I would appreciate any and all of it.

Thanks again,
Pat

[Kingofl337]

Encoders and Ultrasonic are driven by interrupts that we handle for you. On event they take priority over everything else to execute a tiny bit of code.

Normal inputs are monitored via the user code loop speed. So, the smaller the user code is then the faster the inputs get checked. We did not bring out interrupts in easyC/easyC Lib for the user to access.

You may just want to write a program to monitor the loop time and then print it to screen after checking.

[Mike Betts]

All,

This post is a good read...

Mike