RTI Isn't

[Wings]

In my FHSS system I have a period of time when I must detect a 38.4KHz clock coming from my radio chip. I'm using the input capture on a timer to do this. Works fine. I'm also using the RTI in my system (40ms period), but during the time when I'm detecting the clock I have to disable the interrupts from the RTI so it doesn't interfere with my timer ISR (it barely has enough time to do its thing). I do the clock detecting in 56 1.8msec periods. It is during the 1.8ms periods that I clear the RTIE to disable the RTI, and between those periods when the radio chip is changing channels I set the RTIE for a few cycles to allow the RTI to interrupt. If it had timed out during the 1.8ms while the RTIE was clear, I would expect to get an interrupt as soon as I set the RTIE bit. It doesn't.

So the question is, is it normal behavior for the RTI to not interrupt if it times out when its RTIE bit is clear and then the RTIE bit is subsequently set?

(QG8)

[Wings]

RTI is, it's Wingsy that isn't.

To clear the RTIE bit I used.
LDA SRTISC
AND #!(1
STA SRTISC ;STOP THE RTI IRQ DURING CLK SEARCH.

But I should have:
LDA SRTISC
AND #~(1
STA SRTISC ;STOP THE RTI IRQ DURING CLK SEARCH.

Got mixed up on what a 1's compliment operator was in CW assembly.

All OK now. You may resume your normally scheduled activities.

[Wings]

Jeepers, that didn't come out right. The middle line in my code got clobbered by the forum somehow. The part that starts with " (1 " should have been followed with 2 less-than symbols (the shift-left operator) followed by " RTIE) ".

What the secret to pasting in-line code in here?

[bigmac]

Hello Wings,

You also could have used the following expression -

AND  #((1<<RTIE)^$FF)

The use of Courier New font seems to work better when entering code.  Let's see ...

Regards,

Mac