Marcel wrote...

>I have thought of that, but as there is no instruction to test-and-clear a
>variable in a single cycle a racing-condition could occur. Perhaps a
>combination of both solutions to keep the disable-interrupt-period as short
>as possible.
>
>Dave Dilatush wrote:
>> But if interrupt latency is an issue, you can use a different
>> method: have the ISR put the 32-bit integer into a temporary
>> holding register and set a flag bit somewhere to indicate to the
>> main code that a new integer value is available.  The main code
>> can test the flag and when a new value is available, transfer it
>> to the working variable and then reset the flag.  The ISR, in
>> turn, refrains from updating the holding register unless the flag
>> has been cleared by the main code.

There's no possibility of a race condition here, since the flag
enforces strict discipline over the "ownership" of the holding
register between the ISR and the main code: the ISR refrains from
writing to the holding register unless the flag has been cleared
by the main code, and the main code refrains from reading the
register unless the flag has been set by the ISR.  Neither set of
code EVER grabs the register; they can only surrender it.

There's no need for an indivisible test-and-clear (or
test-and-set) instruction in this case, and no danger of a race
condition: while the interrupt can occur at any point in the
execution of the main code, the reverse (i.e., the main code
suddenly "popping up" in the middle of ISR execution) can never
happen.

I use this method routinely for communicating between main line
code and ISRs, in both directions, and have never had any
problems with it.

Dave D.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body