Go to Post I guess Team 999 was like "Chute first, ask questions later". - KPSch [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 5 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #13   Spotlight this post!  
Unread 19-01-2008, 16:08
jleibs's Avatar
jleibs jleibs is offline
Computation and Neural Scientist
AKA: Jeremy Leibs
no team
 
Join Date: Jan 2008
Rookie Year: 2001
Location: San mateo
Posts: 19
jleibs is a glorious beacon of lightjleibs is a glorious beacon of lightjleibs is a glorious beacon of lightjleibs is a glorious beacon of lightjleibs is a glorious beacon of light
Send a message via AIM to jleibs
Re: New C18 3.0+ Compatible FRC Code

Ok, I have a question (more of a comment really), but I was hoping someone could either verify my understanding, or explain what I'm missing.

It seems the current gyro code as well as some things others have mentioned depend on putting processing code inside one of the Spin functions.

Generally speaking, the spin function will be executed at a very high rate (essentially only processor-limited). However, at roughly 38Hz, the spin function is going to get delayed by however long it takes to run your general execution code, e.g., Teleop(). If this code is simple and runs quickly, this isn't likely to be too much of a problem.

However, there is still going to be some delay associated with this code, let's call it T_d. Now, the frequency, 1/T_d is going to be important because it's actually the maximum frequency we can count on our spin function to run at over any arbitrary time interval.

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.

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. 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.

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. Wouldn't it be better to just do the gyro processing in the ISR alongside the analog-to-digital conversion? Then we would have high-frequency reliable processing of the gyro (or whatever other analog sensor we are processing), without having to worry about anything other than keeping our Teleop() execution time a decent amount under the theoretical limit of 26 ms.
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Does the camera code suits to all versions of MPLAB and C18? razer Programming 3 04-01-2007 14:50
Trying to follow C18 interrupt context code... dcbrown Programming 5 21-12-2006 09:01
Error w/ FRC code JamesBrown Programming 2 08-01-2005 16:17
Programming code Fix FRC Ferazel2001 Programming 6 08-02-2004 02:46
FRC default code hedgehogger Programming 2 21-01-2004 18:41


All times are GMT -5. The time now is 10:11.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi