View Single Post
  #6   Spotlight this post!  
Unread 18-11-2003, 14:38
WizardOfAz's Avatar
WizardOfAz WizardOfAz is offline
Lead Mentor
AKA: Bill Bennett
FRC #1011 (CRUSH)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Tucson, AZ
Posts: 101
WizardOfAz will become famous soon enough
Send a message via AIM to WizardOfAz
timing with user_routines_fast

I don't think you can get any timing information by using user_routines_fast. If you look at the bottom of main.c, you see how this is used, and it doesn't help with knowing how much time has passed.

Here's what you see in main.c (slightly edited for clarity):

while (1)
{
if (statusflag.NEW_SPI_DATA) /* 17ms loop area */
{ /* I'm slow! I only execute every 17ms because */
/* that's how fast the Master uP gives me data. */
Process_Data_From_Master_uP(); /* in user_routines.c */
}

/* I'm fast! I execute during every loop.*/
Process_Data_From_Local_IO();
}

The Process_Data_From_Master_uP function is called whenever there is new data available from the Master uP, every 17ms in the EDU-RC and every 26 ms in the big RC. The other one (Process_Data_From_Local_IO) is called every time around the loop. How often this will happen depends on how much is being done in that function, and will also (every 17 or 26 ms) be delayed a different amount while Process_Data_From_Master_uP runs. The main reason they've provided this is in case you want to handle local I/O (pwm and digital I/O that's on the robot, not on the OI) faster than you do the OI I/O.

In other words, yes you will get cycle times much faster than 17 or 26 ms in Process_Data_From_Local_IO, but how much faster is not controlled by anything you can depend on.

Driving an oscillator into the interrupt is a workable idea, I was just hoping that with 6 on-chip timers there would be one that we could use.

Does IFI want to weigh in on this?