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