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

Its a problem because I want to update the display three times per second.
I have other things going on in the isr.  It reads sensors, fires a
solenoid,  shows several different displays.  Some of the displays have to
flash to show error conditions.  Its not an impossible solution, but its not
great either.

>
> 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.
>
Yes, both arrays need simultaneaous samples.

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

Thanks ;-)

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

I think that will work.  Since main can't interrupt the isr, the flag will
either be there or not.  There is no race.  And we don't care about the race
when main resets the flag.  By George, I think you've got it.

Thanks

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.543 / Virus Database: 337 - Release Date: 11/21/2003

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