> -----Original Message-----
> From: Mike Mansheim [SMTP:Michael_J_Mansheim@GRACO.COM]
> Sent: Monday, November 06, 2000 6:22 PM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      Re: [PIC]: Multibyte words and Interrupts
>
> depends...
> I like a flag that tells the isr whether or not the data is valid;
> however, this means that some instances of the interrupt will
> not send any data (the isr just returns if the data valid flag
> isn't set).
> If the variables are double-buffered, then the isr will always send
> data, but it may be the old data.
> I wonder why an isr to i2c the data out??  Why not just put the ic2
> xmit at the end of the variable manipulations in the main while(1)
> loop?
>
The reason for this is that I am using the MSSP in Slave mode, which really
does need to be interrupt driven to  give the fastest response to the
master.

>  If that makes the the xmits happen too often, maintain a
> counter and only xmit every nth time thru the loop.  If that isn't
> precise enough, use the isr to maintain a clock and set a flag
> when it is time to transmit.
> I'm assuming the interrupt is internally timer generated - if it
> is in response to an external request, then the double-buffered
> example you gave could miss the request while the interrupts are
> disabled.
>
Probably didn''t explain the whole thing too well, but the PIC will
essentialy be for real time monitoring of 32 analogue inputs via
multiplexors and 16 or more digital inputs.  It will also have to control 8
digital outputs depending on either the state of the analogue inputs or on a
request from the I2C master.  The master can request the value of any of the
analogue or digital channels.

Now my first idea was to perform all the monitoring and control in the main
loop, and use the interrupt purely for comms.  There is no fixed requirement
for the loop time, this isn't a closed loop control system so the monitoring
does not have to work to an exact period.

Thinking about this a bit further, I guess I could do monitoring under a
timer interrupt.  If I checked the state of the SSPIF flag after every
critical section I could ensure a reasonable latency for the comms, and
there should be no way the I2C should be able to retreive a half written
word.  The main loop would effectively be empty, just a watchdog reset I
guess.

Alternatively, I could move the I2C out of interrupt control and just poll
it in the main loop, but perform monitoring under a timer interrupt.  This
would mean worst case latency would be the entire monitor rouine...unless I
split it up into smaller chunks.

Any comments?  I'm most impressed with the response to this so far!

Mike

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