View Single Post
  #7   Spotlight this post!  
Unread 30-01-2007, 09:36
Mike Bortfeldt Mike Bortfeldt is offline
Registered User
FRC #1126 (& 1511)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Rochester, NY
Posts: 119
Mike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud ofMike Bortfeldt has much to be proud of
Re: concerned about bogging down rc?

Orborde,

Back in 2004/2005 I calculated the processor "free time" by counting the number of times the routine "Process_Data_From_Local_IO" was called in a 1 second period. Since this routine continually gets executed as long as there is nothing better to do (and we didn't have any custom code in it), it's a good way to see how loaded the processor is. In my case it took 14 instruction clock cycles to complete the while loop in "Main.c" as well as the call/addition/return of the "Process_Data_From_Local_IO" routine as long as there wasn't new OI data. With the processor running at 10 MHz instruction clock speed, it was a simple matter to calculate a % free time. We posted this to one of the User_Bytes so we could monitor it on the dashboard, and you could see the % free time change as the number of interrupts varied due to motor speeds (drive encoders mainly).

As for the 8% for the generate_pwms call, it sounds about right. My understanding is that the routine uses a loop to "wait" for the required amount of time to generate the 1-2 msec PWM pulse. Assuming a maximum 2 msec pulse, executed at about 38 times per second, that comes out to a delay of about 76 msec, or about 8% of the processor.

Mike