View Single Post
  #13   Spotlight this post!  
Unread 14-01-2008, 15:59
Guy Davidson Guy Davidson is offline
Registered User
AKA: formerly sumadin
FRC #0008 (Paly Robotics)
Team Role: Alumni
 
Join Date: Mar 2005
Rookie Year: 2005
Location: Ra'anana, Israel
Posts: 660
Guy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to behold
Send a message via ICQ to Guy Davidson Send a message via AIM to Guy Davidson Send a message via MSN to Guy Davidson
Re: New C18 3.0+ Compatible FRC Code

Quote:
Originally Posted by Kevin Watson View Post
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.
__________________

Last edited by Guy Davidson : 14-01-2008 at 19:19.