[jleibs]

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.