Can anyone tell me how to initiate an interrupt on a UNO. What I want to be able to do is to use an Infra Red receiver to create an interrupt on receipt of a particular signal. Would the IR receiver pin have to be connected to a particular pin on the Arduino Uno.?
You want to configure a Pin Change interrupt.
Nick Gammon has an excellent article here about interrupts:
PetriH:
You want to configure a Pin Change interrupt.
It is easier to use one of the external interrupts (Pins 2 and 3 on an Uno)
If you use the Pin Change interrupts you have to check which pin was interrupted.
Nick Gammon's web page should make it clear.
...R
Personally I don't think you're using the right tool for the job. PIR detectors don't operate at particularly high speed. If your response to the PIR detection can afford to wait a few millionths of a second, I'd be inclined to just check it within the loop function like any other input.
Robin2:
If you use the Pin Change interrupts you have to check which pin was interrupted.
Not if only one pin change interrupt is enabled for that particular set of pins.
Nick Gammon's web page should make it clear.
He points out that you need to check but in his examples he doesn't check. He doesn't have to.
jboyton:
Not if only one pin change interrupt is enabled for that particular set of pins.
If you only need one interrupt and use an external interrupt you don't even need to explain this.
However, as @KenF says, don't use an interrupt if you don't need it.
...R
Thanks everyone for the input. It looks as though it would be simpler ad easier to just check for input from the receiver in the normal operational loop.
owddabbler86:
What I want to be able to do is to use an Infra Red receiver to create an interrupt on receipt of a particular signal.
If it's an IR receiver, as in the kind of thing that reads a tv remote, then the sensible way is to use Ken Shirriff's library.
Your use of the phrase "receipt of a particular signal" makes me think this is receiver like that, not a PIR sensor such as KenF's take on your question. If it is a PIR, whose only signal is to turn on when it detects a disturbance, then no, no interrupt required and there's code for that eg here at adafruit.
Robin2:
If you only need one interrupt and use an external interrupt you don't even need to explain this.
Are you sure? The project I'm currently working on has only one interrupt. I can't use an external interrupt, at least not without hacking the hardware. Using a pin change interrupt makes perfect sense.
I could probably implement it through polling instead but it would be ridiculous.
However, as @KenF says, don't use an interrupt if you don't need it.
That's just dogma. If an interrupt were a better solution to a particular problem why not employ it?
jboyton:
I can't use an external interrupt, at least not without hacking the hardware. Using a pin change interrupt makes perfect sense.
I'm curious. Why not? And why does the pin change interrupt work?
That's just dogma.
You are perfectly correct. It is based on my experience that the people who ask questions here probably don't know how or when to use interrupts and don't know know how to debug code with interrupts - which is difficult when you don't know how. Consequently it is easier all round to steer newcomers away from them except in the special case where the newcomer is specifically trying to learn how to use interrupts.
...R
Robin2:
I'm curious. Why not? And why does the pin change interrupt work?
The shield PCB connects the signal to pin 8, not 2 or 3. I could cut the trace and solder a wire but it's easier to use a pin change interrupt. Since there is no other PC interrupt in my project and the code is watching for both rising and falling edges there is no difference in the ISR itself.
I don't understand the second question. Why wouldn't a pin change interrupt work?
You are perfectly correct. It is based on my experience that the people who ask questions here probably don't know how or when to use interrupts and don't know know how to debug code with interrupts - which is difficult when you don't know how. Consequently it is easier all round to steer newcomers away from them except in the special case where the newcomer is specifically trying to learn how to use interrupts.
I understand that. But I don't believe discussing nuances in the presence of a beginner is necessarily a bad thing. It sounds like dabbler86 sees what's going on.
jboyton:
I understand that. But I don't believe discussing nuances in the presence of a beginner is necessarily a bad thing. It sounds like dabbler86 sees what's going on.
There are a number of issues.
Half the time you find that, for one reason or another, you can't carry out everything necessary to service the needs of the interrupt within the ISR. So instead, you end up just setting a variable, that then gets seen within the main body of the sketch and dealt with accordingly. If you're going to do this, you might just as well make the check for the condition THERE in the first place, This keeps the detection and action together.
Another issue is that the ISR can occur at any time. Not only does this have a bearing on the sketch that you see, but can also have unforseen ramifications on the library functions that, chances are, you'd have no reason to look over otherwise.
For example,
You may have a sensor of some kind that you read by calling a library function SomeSensor.read(). This libarary function may be in the middle of reading some serial data from your sensor when suddenly your PIR ISR routine pops up, totally destroying the timing of the stream.
All in all it can lead to bugs that can be very troublesome to trace. I avoid them where they are unnecessary. Using them just for the sheer hell of it can be interesting, but not, imho, good practice.
Ken, I agree that using interrupts "for the sheer hell of it" isn't good practice. But that's not the same as saying polling is always better practice. It's easy to come up with hypothetical situations that demonstrate the value of either approach.
jboyton:
I don't understand the second question. Why wouldn't a pin change interrupt work?
I had not realized that you were using the pin change interrupts because a shield made access to the external interrupt pins inconvenient. I thought there was some software reason for your choice.
...R
Sigh! I try and avoid clearly inflammatory topics! But not entirely successfully. 
jboyton:
That's just dogma. If an interrupt were a better solution to a particular problem why not employ it?
If an interrupt is a better solution to a particular problem, that's good. But that is almost never the case where the device to be sensed is a Human Interface or its status is expected to affect the flow of the main program or servicing the interrupt will necessarily take significant time (such as serial or graphic output). And these constitute the vast majority of questions here (and in "Programming Questions").
There is also the principle that where you need to use interrupts, you will generally have sufficient experience behind you to figure it out. And of course, many libraries are powered by interrupts and perform their functions for you more-or-less seamlessly.
KenF:
There are a number of issues.Half the time you find that, for one reason or another, you can't carry out everything necessary to service the needs of the interrupt within the ISR. So instead, you end up just setting a variable, that then gets seen within the main body of the sketch and dealt with accordingly. If you're going to do this, you might just as well make the check for the condition THERE in the first place, This keeps the detection and action together.
And that's not necessarily true either; the interrupting event may be relatively infrequent, but briefer than the cycle time of the polling loop.
I'd be keen to hear back from the OP about my thought in reply 7 as to whether by IR he means PIR or modulated IR ala TV remote style for example. OP's use of the phrase "receipt of a particular signal" leads me to suspect the latter.