Today, I had a little time to spare with a frequency counter and a VEX micro. (I am using the MPLAB C programming environment.)
I re-wrote the user code to only execute my code fragments and nothing else (no reading of the receiver channels and no assigning values to pwm outputs - it just runs my code chunks.) My first experiment was to set IO15 to an output and toggle it. Here is the code chunk called from user_routines.c
void TestRoutine(void)
{
// Simply toggle the output between 1 and 0
rc_dig_out15 = !rc_dig_out15;
}
The frequency counter showed about a 37 millisecond period. Since user routines runs twice per cycle on IO15, that means the cycle time is 18.5 milliseconds. This timing became synchronized when I turned on the transmitter. Thus, the VEX micro seems to synch up to the transmitter packet rate. This may seem trivial to most of you but the next code segments are more interesting:
void TestRoutine(void)
{
// Simply toggle the output between 1 and 0
rc_dig_out15 = !rc_dig_out15;
printf("variable %2x\n",(int)rc_dig_out15);
printf("this is a big honkn' super duper long printf statement to the terminal\n");
printf("this is another big honkn' super duper long printf statement to the terminal\n");
}
The 160 ASCII characters in the printf statements do not alter the repetition rate of the user_routines.c! The period gets longer when I add a copy of the last printf line. Two conclusions can be made. 1) Too much text slows the user_routines repetition rate. 2) One would have to write a lot of code to get an equivalent slowdown. Thus user_routines.c is a very safe bet for consistent timing.
Next, I moved the test code to user_routines_fast.c. Things get more interesting here.
void Process_Data_From_Local_IO(void)
{
/* Add code here that you want to be executed every program loop. */
rc_dig_out15 = !rc_dig_out15;
}
Setting the freq. counter to frequency (instead of period), I get about 455KHz. The interesting part is that the frequency dips occasionally. This must be due to other processes. Simply adding one more line of code to increment a variable slows the frequency down to 350KHz or so (I don’t remember exactly.) The more code I add, the slower it gets. The random dips in frequency are still there.
Conclusions: 1)The user_routines_fast.c is blazingly fast compared to the regular user_routines. 2)It appears that the repetition rate varies “randomly”. 3)This random variation may make digital PID or filters difficult as the integration and differentiation components are repetition rate dependent - necessitating some other means of getting an accurate timebase. 4)The repetition rate is greatly affected by the amount of code you have running in the user_routines_fast.c. 5)Getting data into and out of IO15 was completely independent of user_routines.c or the transmitter on/off.
The last conclusion is way cool because, with the speed of user_routines_fast.c, I can easily handle all my optical sensors through regular IO ports without using interrupts!!!
What is better is that the IO ports function with or without the transmitter on.
Now that I don’t have to mess with interrupts for the optical sensors, life just got a whole lot simpler.
This may be duh info for some folks but I hope it simplifies life for some others like it has for me.
EJ
P.S. Since the motor pwm outputs have a pattern repetition rate of 18.5 milliseconds, updating pwm values in user_routines_fast.c would make no sense (updates ocuring too fast for the motor pattern). Still keep the updates in the regular user_routines.c
