Serving interrupts while waiting for IR input

[ocwo92]

I have a 08M based application that is intended to just sit there and wait for either user input via IR or an interrupt based on activity on pin 2. Ideally, the program should simply sit at:

' Wait for a key.
infrain2

but immediately execute the interrupt routine if activity is detected on pin2, which has been configured with:

setint %00000100, %00000100 ' interrupt on pin 2 high

However, it appears that interrupts aren't served while infrain2 is executing.

Is there a way to poll for IR activity in a loop instead, which should allow the interrupt to be served?

 

[hippy]

Welcome to the PICAXE Forum.

You can poll for IR as most IR is sent multiple times while the button is held but that's not perfect as INFRAIN2 can still jam if that IR comes from a remote that INFRAIN2 doesn't recognise.

With other PICAXE you can use IRIN with timeouts but otherwise it's a choice of bit-banged IR receive rather than INFRAIN2 or using another PICAXE to take IR which the main PICAXE can poll.

 

[ocwo92]

You can poll for IR as most IR is sent multiple times while the button is held but that's not perfect as INFRAIN2 can still jam if that IR comes from a remote that INFRAIN2 doesn't recognise.

Thanks. I attempted to poll with the following code snipped:

    infra = 128 ' invalid IR value for polling
waitforir:
    if infra > 127 then waitforir

but this doesn't seem to work for me (except the interrupt is now served). How do I poll for the IR value on the 08M?

 

[matherp]

I solved a very similar issue as follows:

IR input using a 08M, for each valid character read output a single code character with serout.

Background hardware serial receive on a 20X2 and inputs from a rotary encoder firing interrupts which put pseudo serial data into the h/w receive buffer. Main loop sitting waiting for the h/w serial pointer to move and then processing as required

The application was to control the volume/balance/channel selection of an amplifier via either the rotary encoder or an IR remote.

This approach works very well but does seem a bit over the top.

I would also be interested in any innovative solutions to this category of problem

Thanks

Peter

 

[hippy]

You need to monitor the level of the pin the IR receiver connects to. For the 08M that's Input Pin 3, and the signal goes low when IR is present, so ...

#Picaxe 08M
#Terminal 4800
Do
  If pin3 = 0 Then
    SerTxd( "Code=" )
    InfraIn2
    SerTxd( #infra, " " )
  End If
  SerTxd( "- " )
Loop

You should see lots of "-" while the code loops, the IR code number when a key pressed. Take a non-Sony IR and you'll see it stop with "Code=" when a key pressed, that jam in INFRAIN2 mentioned earlier.

The 'infra' variable you tried to use will only get updated when the INFRAIN2 command gets executed.

 

[Michael 2727]

To work around Infrain2 locking up a routine while waiting.
Simply "count" the IR pulses rather than decoding it, then jump to your Infrain2 code.

COUNT pin, (short sample time) e.g. 400 into variable.
If you only select valid (=) pulses of x 13 (Sony IR) 13, 26, 39, 52, 65, 78 this
will give you some immunity to false triggering.

A brief burst from the IR Remote will initiate the jump to a true Infrain2 part of your code.

 

[westaust55]

@ocwo92,

If you have a read of PICAXE Manual 2, in Appendix 4 you will see that interrupts are disabled while certain commands are in operation. Namely:
Serial: serin, serout, serrxd, sertxd, debug
One-wire: owin, owout, readtemp, readtemp12, readowsn
UNI/O: uniin, uniout
Infra-red: infraout, irout


and although not specifcally mentioned, I would suspect that the new RFIN and RFOUT commands also fall into that category as well.

 

[ocwo92]

One possible solution

I found a workaround:

symbol irreceiverpin = pin3

	' Wait for a key. Poll in order to allow interrupts.
waitforiractivity:
	if irreceiverpin = 1 then waitforiractivity
	infrain2

The code probably works because the key is being retransmitted while pushed.

 

[westaust55]

I found a workaround:

symbol irreceiverpin = pin3

	' Wait for a key. Poll in order to allow interrupts.
waitforiractivity:
	if irreceiverpin = 1 then waitforiractivity
	infrain2

The code probably works because the key is being retransmitted while pushed.

Yes, commercial handheld IR controllers, as a minimum, repeat the code associated with a pushbutton several times with a brief pause of the order of 45 ms between each transmission.

 

[hippy]

I found a workaround:

Yes, that's a variation of the mechanism I suggested in Post #5, but also read the caveats in that post - If IR is detected you will then execute the INFRAIN2, but if it's not IR from a Sony TV remote or something compatible the program will still jam waiting on INFRAIN2, interrupts will not be handled at that time.

With my test program that also jams at times even with a Sony TV remote because of the delays the SERTXD add. The end of an IR transmission may be seen as indication of the presence of IR but if that is the end of transmission no data arrives for INFRAIN2 to receive. Quick key presses aren't always detected.

Michael 2727's suggestion in Post #6 is a better test for IR present than a simple 'if pin is low' test.

There's no perfect solution to handle interrupts and IR together with INFRAIN2 but the workround does make things better. If the PICAXE stops responding to interrupts, simple send it some Sony TV IR and it should come back to life.

 

[ocwo92]

Yes, that's a variation of the mechanism I suggested in Post #5, but also read the caveats in that post - If IR is detected you will then execute the INFRAIN2, but if it's not IR from a Sony TV remote or something compatible the program will still jam waiting on INFRAIN2, interrupts will not be handled at that time.

Fortunately that's not an issue in this application. The most important thing is a fast interrupt response.

 

[hippy]

I'm not sure how it's not an issue as it's a demonstrable flaw in the design which could manifest itself at any time, and when it does, it will prevent interrupts being handled. However it is your decision to make on what is acceptable for your application.