Bruce Partridge wrote:
> I have a difficult situation like this now.  The interrupt routine
> needs to update some real time data.  Every 4 seconds it writes two
> arrays of 16 float variables.  It takes the isr 150 ms to calculate
> and write the arrays.
>
> The main routine takes copies of these arrays, and runs for 5-15
> seconds calculating secondary display items based on the data at that
> moment in time.
>
> 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.

This doesn't make any sense.  You are only updating the data every 4
seconds, and only processing it every 5-15 seconds.  What's the big deal
holding off interrupts while the main routine makes a copy of the arrays?
The interrupt won't get lost, just delayed 66mS according to your figures.
Since you've got 4 seconds to do 150mS of processing, this doesn't sound
like a problem.

Do both arrays need to be from simultaneous samples?  If not, you could
disable interrupts separately around each of the two array copies.  That
will further reduce the interrupt latency.

> If I create some sort of "write in progress" flag, it will be set and
> cleared without main seeing it.

That's why you don't do it that way.

> 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.

Then you can have the interrupt routine set a flag whenever it writes new
data.  The main routine clears the flag before the copy, then recopies if it
finds it set after the copy.

> 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.

It's not very elegent, but doesn't require any more memory.  You don't need
a third buffer to compare the copy to the live values.  However, it's less
code and faster checking the flag at the end and recopying if necessary.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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