Quote:
|
Originally Posted by Astronouth7303
It's not that, it's that the main loop has different iteration times depending on what is executed.
|
Do you mean "execution times"? I take "iteration time" to be the time between iterations of the 26.2 ms loop area. I actually measured this with a scope on Saturday, it was very interesting:
Code:
while (1) /* This loop will repeat indefinitely. */
{
if (statusflag.NEW_SPI_DATA) /* 26.2ms loop area */
{ /* I'm slow! I only execute every 26.2ms because */
/* that's how fast the Master uP gives me data. */
rc_dig_out17 = 1; // take pin 17 high
Process_Data_From_Master_uP(); /* You edit this in user_routines.c */
if (autonomous_mode) /* DO NOT CHANGE! */
{
User_Autonomous_Code(); /* You edit this in user_routines_fast.c */
}
}
Process_Data_From_Local_IO(); /* You edit this in user_routines_fast.c */
rc_dig_out17 = 0; // clear pin 17 /* I'm fast! I execute during every loop.*/
} /* while (1) */
This made a pulse of about 4 ms in duration (the "exectution time" of my code), with a (measured) cycle time ("iteration time") of about 26 ms. Hitting certain buttons would change the 4 ms to something else like 3 ms as my code changed modes, but the period remained 26 ms. It seemed pretty rock-solid. Except when very strange things were happening; see my earlier
post on that. But that was something broken.
One reason a delay might be useful is to reduce the frequency of calls to Generate_Pwms(). See the reply from Kevin Watson to the post mentioned above.
-Norm