Thread: Interupts/sec
View Single Post
  #2   Spotlight this post!  
Unread 09-10-2006, 15:02
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,186
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: Interupts/sec

It's all relative to what you are doing. Encoder.c isnt actually doing much work except for initializing the interrupt to detect on a rising edge and holding the interrupt handler. It really all depends on what else you are doing in the code. If you are running default code, you will be able to service more interrupts without over budgeting your time period to report back to the master processor. Likewise, if your code is fairly complex your ability to service a ton of interrupts will be brought down. We ran into this problem last year with encoder interrupts, serial interrupts, and a full field navigation system running on the RC at all times. We ended up putting a switch on the robot to turn serial on and off because our robot would reset about 5 times per match.

I guess think of it as a pizza. Half of the pizza's toppings can be interrupts, half can be regular routines. You don't have to eat the whole pizza (processing time), but you certainly can't eat more than you have been given.