View Single Post
  #257   Spotlight this post!  
Unread 19-01-2008, 17:44
Kevin Watson's Avatar
Kevin Watson Kevin Watson is offline
La Caņada High School
FRC #2429
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 2001
Location: La Caņada, California
Posts: 1,335
Kevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond repute
Re: New C18 3.0+ Compatible FRC Code

Quote:
Originally Posted by jleibs View Post
Right now it looks like we are processing our Gyro at 50Hz? (800Hz / 16 samples per update). This means we need to make sure that T_d < 20ms or else we will occasionally miss gyro samples.
Your average does need to be less than 20ms over time, but it's 40ms before you actually miss data.
Quote:
Originally Posted by jleibs View Post
I agree that if T_d is pushing 20ms, you're probably going to have other problems since that's a lot of computation going on.
Agreed. If the execution rate is somewhere between five and ten million instructions per second, you can, on average, execute somewhere between 100,000 and 200,000 instructions per Teleop() loop even with the ISR overhead. If you're trying to execute 100,000 instructions in the Teleop() loop, missing an occasional ADC update is the least of your problems. I didn't point this out in the documentation, but you can determine if you're dropping data by testing the value returned by Get_ADC_Result_Count(). If it's two or greater, you're dropping data.

Quote:
Originally Posted by jleibs View Post
I mostly wanted to clarify this in the case someone was thinking about trying to sample an analog signal at a data rate higher than 1/T_d (probably somewhere in the 800Hz - 6400Hz range), and still do the processing in the spin loop. In this case they might start seeing data go missing every once in a while.
As I've stated elsewhere, I test the code with the ADC running at 6400Hz/4 samples per update, one encoder generating several hundred interrupts per second, several printfs generating a lot of telemetry in the Teleop() loop and as far as I can tell, everything works just fine (with the old 2.4 compiler I do see an occasional corrupted telemetry packet for reasons I don't fully understand; code generated with the 3.1 compiler doesn't have this problem).

Quote:
Originally Posted by jleibs View Post
I guess my question then is why do we count on the spin code to do our processing since it's timing seems potentially sporadic.
Like I said above, I think (er, hope ) it's a non-problem.

Quote:
Originally Posted by jleibs View Post
Wouldn't it be better to just do the gyro processing in the ISR alongside the analog-to-digital conversion?
This is how my code worked originally. The downside is that it's a lot of code to execute in a ISR and the ADC was dedicated to the gyro and nothing else could be sampled. After getting many requests, I split the ADC code away from the gyro code and provided a API to the ADC so that other sensors can be used alongside the gyro.

-Kevin
__________________
Kevin Watson
Engineer at stealth-mode startup
http://kevin.org