View Single Post
  #11   Spotlight this post!  
Unread 20-10-2010, 19:21
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,880
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: How do I use interrupts?

Quote:
Originally Posted by Jon236 View Post
Mark, if you handle the interrupt with the Event Case inside the While Loop, doesn't the Interrupt Wait vi handle the interrupt reset for you while you do whatever you want in the Event Case? I would think you would just want to write to a FGV or Global to allow a parallel process actually DO something.
This depends on what you're trying to do and the time you have to accomplish it. The answer gets back to the question Ether asked, "What is the application?"

In a traditional Interrupt Service Handler (ISR) what you say is very true. You do want to get out of it just as fast as possible, usually by simply setting a flag or incrementing a counter, and then leaving further processing up to some independent polling task or triggered process.
A traditional example would be an encoder where interrupts come fast and furious and you must make sure they are all captured and counted. In this case the reset/repeat elapsed time is much too fast to waste time process when you could be missing subsequent interrupts.

I may be reading too much between the lines here...
but this doesn't sound like a rapid-fire response ISR though. This sounds like an event trigger.

This application, what little we know of it, is a micro-switch which is quite a slow (& noisy) device, especially when you take into account the debouncing delay that will probably be required (and that you have to add). An interrupt is not usually a good solution for a mechanical switch, because of all the false interrupts that get generated when a switch makes contact just once. Your code will probably run several times in a row on a single switch press. It probably won't matter which edge you chose as you'll most likely get both rising and falling edges at the same time, whether the switch is being pushed or released.

So, I'm imagining that they just want to react to the switch getting hit just as fast as computerly possible, with a relatively long (for the cRIO) delay afterwards to do whatever it is they plan to do.
Say the switch is just intended to trigger an event like "kick a ball" when it hits the switch, then that's a slow process that could do all it's processing in the interrupt handler. Primarily because you don't want it to happen again until the mechanism has recycled/reloaded. Code has to be added to delay long enough to debounce the switch anyway.

When designing your code you need to take into account how fast you need to be able to repeat the process, whether the process is locked until recycled, etc.

P.S.
I don't think this Interrupt function stores events. I think it will only "hear" interrupts that occur while Interrupt Wait is active. So the entire time spent in the React case will be deaf to further interrupts.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 21-10-2010 at 13:46. Reason: Simplifying a tiny bit.
Reply With Quote