Actually, you only need one flag

volatile bit inCriticalRead;

mainline code:

    do {
        inCriticalRead = 1;
        <copy the data>
    }
    while (inCriticalRead = 0);
    inCriticalRead = 0;

interrupt handler:

    inCriticalRead = 0;


Bob Ammerman
RAm Systems



----- Original Message -----
From: "Mark Hore" <baerwulf@ECHIDNA.ID.AU>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Monday, December 22, 2003 9:26 AM
Subject: Re: [PIC:]Two low priority long tasks with several high priority
short tasks.


> On Mon, 2003-12-22 at 01:54, Bruce Partridge wrote:
> > > 2. Race Conditions.
>
> ...
> > If I have the isr set a semaphore saying that it is updating the arrays,
> > then main can wait.  But if main is making the copy, and the interrupt
> > fires, the arrays will have part old and part new data.
>
> This is the expected behaviour. The ISR should disable interrupts when
> called. Your interrupt routines should not ever be preempted.
>
> > I can't tell the isr not to update, because this data is what the app is
all
> > about.  If I turn off interrupts, I introduce 66ms of latency during the
> > copy of the arrays.  That takes a lot of time from the isr to do the
things
> > it needs to do.
>
> How important is each data point? What is the effect on program function
> / accuracy if a data point is missed. You may need to risk missing data
> points to resolve this problem.
>
> > If I create some sort of "write in progress" flag, it will be set and
> > cleared without main seeing it.
> >
> > A "new data available" flag doesn't prevent the isr from updating it
while
> > main is in the process of copying.
>
> >From your description what you need to do is use a flag (semaphore) to
> tell the ISR that main is using the resource and therefore the ISR
> should wait. You potentially will lose data points. Again, how critical
> is each point?
>
> > Since main is not time sensitive, I don't mind having it to recopy if it
got
> > a bad copy, but I don't know how to let it know.
>
>
> one solution may be:
> 1. declare two (bytes || bits) for flags - flag inCriticalRead and flag
>         updatedWhileRead.
>
> 2. at beginning of array copy in main set inCriticalRead and clear
> updatedWhileRead. Do this before copying any data.
>
> 3. at the end of the ISR array update routine if inCriticalRead is set
> then set updatedWhileRead.
>
> 4. after copying arrays if updatedWhileRead is set then go to the
> beginning of the array copy (2.) else clear inCriticalRead and continue.
>
> This all assumes that the array copy can complete in the delay between
> one ISR period and another. The whole solution shouldn't add more than a
> dozen or so instructions to your code if you are writing in assembler.
> Your mileage may vary for C or other languages.
>
>
> > Making two copies and comparing them is one way, I suppose.  Keep doing
that
> > until I get two identical copies.  But its not very elegant, and it uses
a
> > big chunk of memory that is tight already.
>
> This would be messy and ugly and wasteful. Please avoid if at all
> possible
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu