View Single Post
  #12   Spotlight this post!  
Unread 14-04-2014, 19:02
wireties's Avatar
wireties wireties is offline
Principal Engineer
AKA: Keith Buchanan
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Rockwall, TX
Posts: 1,170
wireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond repute
Send a message via AIM to wireties
Re: using interrupts in FRC

Quote:
Originally Posted by AustinSchuh View Post
We have used interrupts on the cRIO before in previous years, and my advice is to run away screaming.
I tried to use interrupts this year and concur - something is flaky. But it is somewhere in the library or the FPGA. Interrupts are used on FRC robots for the main timer, for the arrival of network data and many other purposes - so they do work. In my case interrupts would fire for a while and then stop firing. The rest of the code continued to run (not crash as in Austin's case) but the limit switch I tied to the interrupt pin just stopped generating interrupts.

There is a list of OS functions (not to call) in the VxWorks Programmer's Guide. Basically do not call anything that only makes sense from a task context (no taking semaphores, no delays, no memory allocation, no formatted I/O, no mutexes, doing anything that might block etc) plus no floating point math (unless you save/restore the floating point context).

In Austin's example my (wild) guess is that the source of the interrupts (occasionally) did not get turned off. If more interrupts occur than the VxWorks can handle its internal queue will overflow (something like a Windoze BSoD).
__________________
Fast, cheap or working - pick any two!