Back to solving the OP's problem, rather than the question, I think you need
to look at your code design. It's always possible to use some kind of ISR
originated signal to efficiently control a main thread of execution.

There are two design methods to achieve what you're trying to do:-

1. You could make your ISR either signal directly with a specific purpose
flag that the main thread should stop playing the sound
 - you tried this and it was too slow.

2. You could make your ISR modify the data or parameters that the other
thread is using, so that it prematurely reaches an end condition.

To explain, imagine that your main thread was playing a (digital sample) by
streaming bytes from RAM to an IO port (which would have an ADC on it). Your
program loop would likely look something like this:-

        loop:
                        counter++
                        retrieve next byte
                        send byte to port
                        if counter >= end of data then exit the loop
                        goto loop

In this scenario, your isr could just modify counter so that it was set to
the end of the data. This would make the main code thread exit that loop.
And you haven't introduced an extra branch or condition evaluation for doing
it.

Obviously, your code will be vastly different, but there is always a way to
design it so that you can satisfy one of the above mechanisms.


Thanks

Jon

> -----Original Message-----
> From: Jinx [mailto:joecolquitt@CLEAR.NET.NZ]
> Sent: 24 October 2003 00:19
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC:] Not returning from an Interrupt.
>
>
> > In a nutshell, what I wanted to know was if it was obligatory to
> > RETFIE at the end of an ISR. After getting some answer from
> this list
> > and reading the datasheet I decided that it is not
>
> Normally one would treat interrupts and RETFIE as
> complementary. This keeps things "tidy". There is no
> obligation to do this but you have to be aware of the
> consequences. Not popping PC off the stack by leaving the ISR
> could be troublesome at a later time unless the s/w is
> written to take account of this skeleton in the cupboard. It
> could be said that that once you've entered a section of code
> because of an interrupt, while the return address is on the
> stack you're still in the ISR, which may or may not be
> relevant to how or whether the code keeps running. You could
> change to a micro that can POP the stack
>
> --
> http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads