>
> If I have a main loop that uses a lot of 16 and 32 bit variables which need
> to be accessed (but not changed) in the ISR for sending the values accross
> an I2C bus. Is there a good way to ensure a whole word has been loaded
> before an Interrupt is serviced?  i.e. if a 16 bit word is being updated in
> the main loop, this will obviously take at least 2 operations, probably more
> like 4.  If an interrupt occurrs in the middle of this, the word will
> neither contain the new value or the old value, but a bit of each, which is
> obvioiusly undesirable.  Switching off interrupts for every multibyte
> operation dosen't seem very practical.  I'm thinking that maybe I should
> double buffer the variables I'm interested in, and only use the buffered
> copies in the ISR...
>
> e.g.
>
> int a,b,c,d;
> int buff_a,buff_b,buff_c,buff_d;
>
> void main()
> {
>
>         while(1)
>         {
>                 /* lots of 16/32 bit operations in main loop */
>                 a = (b*c)+d;    /* etc....etc....*/
>
>                 /* end of loop */
>                 while(GIE) GIE = 0;     /* disable interrupts */
>                 buff_a = a;             /* copy variables to buffers */
>                 buff_b = b;
>                 buff_c = c;
>                 buff_d = d;
>                 GIE = 1;                /* enable interrupts */
>         }
> }
>
> So, what I would like to know is if there a better way of doing things that
> dosen't use so much RAM?
>
> Cheers
>
> Mike
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use RemoveMElistservTakeThisOuTspammitvma.mit.edu?body=SET%20PICList%20DIGEST

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