Quote:
Originally Posted by Kevin Watson
My thought was to not even have an ISR and just keep an eye on your 100Hz timer interrupt flag with code located in teleop_spin() and/or autonomous_spin(). Just setup and start a timer, but don't set the interrupt enable bit to one, which will prevent the processor from calling the low priority ISR. Then with code like this in *_spin():
if(INTCONbits.TMR0IF)
{
// Get encoder counts
// Calculate position/velocity
// Do PID calculations
// Update PWM values
//reset interrupt flag
INTCONbits.TMR0IF = 0;
}
...you can implement your 100Hz contol algorithm.
-Kevin
|
Ahh. I understand. No ISR at all. That would make it run slightly slower than 100hz, but will probably help performance slightly (due to the lack of the ISR). Thank you very much.
EDIT: Actually, I am not sure if it will run any more slowly at all. This looks great.
EDIT 2: Timer 0 does not seem to have the support to run to a predetermined value like timers 2,3,4. Should we use timer 2 instead? Another question. None of these timers actually allow us to run a 100hz cycle, even with 1:16 pre- and post-scalers. The slowest we can do is 150hz. Am I missing a way to do it, without using a second flag, or should we just use 150hz (or a double flag)?
EDIT 3: I just ran into another potential obstacle. Our calculations say that we will get at most 15 ticks from the encoder per cycle. That does not seem like a very high resolution. We're currently trying to see if this will actually be an issue, and if so, what we could do about it.