View Single Post
  #10   Spotlight this post!  
Unread 14-04-2014, 13:39
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 803
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: using interrupts in FRC

Quote:
Originally Posted by Ether View Post
A team has code which uses 100ms and 20ms periodic tasks, and they are running low on throughput margin (i.e. CPU usage is too high). They think that they can reduce CPU usage by using interrupts instead of periodic tasks. What say you?
We have used interrupts on the cRIO before in previous years, and my advice is to run away screaming. Most of the times, they work quite well, but occasionally, we would get a full cRIO reboot without any debug information coming back from the cRIO about why. Our programmers very carefully read the docs on what instructions were and weren't allowed in the interrupt, and were handling the interrupt by incrementing a semaphore which would then wake up a high priority task to do the actual work. The code was looked over with a fine tooth comb. Maybe we were still managing to do something wrong, but given the number of matches that it cost us where we either sat dead or were stuck in an infinite reboot loop, we won't be doing it again.

In our case, we were using the interrupts to capture an encoder value when a magnet would pass over a zeroing hall effect. In my opinion, this is a perfect use case for using an interrupt where you want a very fast response time.