Can interrupts be interrupted ? Is there a workaround ?

[zonemikel]

Basically I'm using a rcr and rct 433 mhz transmitter from radiotronix. The receiver is getting tons of garbage so I'm filtering it out by scanning the input for a "id" or "preamble" before I actually process the input.

I have a interrupt set to fire when i receive transmission on the pic. This checks the first two chars coming in to see if they match the "id" if so it processes the third char as valid info.

My dilemma is that if it receives the first correct char in the "id" it will hang and wait for the next char. So in the odd quinkydink that another char does not come in quickly this will cause the unit to hang while waiting for the next char to come in.

The solution I came up with was to use a timer1 based interrupt that fires every .52 seconds and basically stops all motors and resets the interrupts, so the pic will go back to other processing instead of waiting. And since the rda interrupt resets the timer1 timer, the timer1 interrupt should not be called unless there is no valid input for .52sec. I dont think the timer1 interrupt is able to interrupt the rda interrupt.

I'm using a 4Mhz internal and a pic 887. I calculated .52sec by (1/4e6)*8*2^16=.52

So my question(s) are these
1.) can one interrupt interrupt another
2.) where will processing return when leaving a interrupt ? (eg. where will pc point to, where it was b4 going into the int?)

Here is some code too look at

[Ttelmah]

First answer. No.
Unless you go to a 18 family PIC, where you can have a higher hardware priority for interrupts.

Second part. Old answer. Don't sit waiting in interrupts for things. The RDA interrupt is saying 'one character is waiting to be read'. Read just that one charcater, put it into a RAM buffer (look at ex_sisr.c) and get out of the interurpt. Then in your main code loop, use a state machine. Have this sit in state '0'. When the correct first character is seen, advance to the next state. When the second correct charcater is seen, move to the next state. You can either wait in later states, with an interrupt driven timeout, or keep doing other things till the code advances to the 'I have seen the right message' state.

Best Wishes

[newguy]

Working code: http://www.ccsinfo.com/forum/viewtopic.php?t=23953

[zonemikel]

Thanks, I was looking all over the place to see if interrupts can interrupt interrupts but of course thats not really a search engine friendly term.

Ya i should just get the hell out of the int, I knew i was in there too long. I'll do the state machine like you said.

Oh and I love the lock code nice . . .

Just wondering you have the "enable tbe" interrupt commented out, did that part work ? I'm going to need transmit buffers and such also. I love your code I'll do something similar in mine, that gives me a lot of flexibility since I plan on making my own packets and sending them.

You were getting 9600bps on a wireless connection ...
_________________
Smart people know how stupid they are.

[newguy]

The TBE interrupt is commented out because the wizard puts the enable there. Leaving it there will cause the PIC to hang because it's not handled properly. Have a look through the code and you'll find that the TBE interrupt is only enabled when you have data to send.

The 9600 baud rate was used (if I remember correctly) because the modules the guy was using used 9600. The code, as configured, is capable of any speed - but - the wireless links may not work too well at higher speeds. Start slow and work your way up until you find the limit of your wireless link.