One method that I have used involves the use of three flag bits.
One flag bit is called main_wants_new, one is called isr_wants_new,
one is called allow_data_in_isr, and the last is called data_ready.

How many of these bits you need depends on what kind of data problem
you are faced with. See details below.

***** Answer to Problem 1:

> Problem 1: We want to guarantee that interrupt level can always get a
> 'reasonably current' and consistent value of the variable as set by task
> level. (ie: value is never written by interrupt level code)
>

Isr polls allow_data_in_isr. If that flag is high, then it polls
data_ready each time isr executes. When it finds data_ready
is high, it uses the data and clears data_ready.

When the main program has new data it clears allow_data_in_isr
(this prevents isr from using data while it is being loaded).
New data is loaded into the shared data variable(s),data_ready is
set high, and allow_data_in_isr is set high.

****** Answer to Problem 2:
>
> Problem 2: We want to guarantee that task level can always get a 'reasonably
> current' and consistent value of the variable as set by interrupt level.
> (ie: value is never written by task level code) (hint this is rather easy)
>

Isr polls allow_data_in_isr. If it is low, it skips loading new data.
If it is high, it loads new data and sets data_ready.

Main program clears allow_data_in_isr to ensure no updating occurs
while it looks at data. If data_ready is high it now processes
data and clears data_ready. If it is low it skips data processing.
Allow_data_in_isr is set high to re-enable updating of data by isr
in the background.

The above main program segment may be in the form of a loop, if that is
desired.

***** Answer to Problem 3;
>
> Problem 3: We want interrupt and task level both to be able to write to the
> variable, and always get a 'reasonably current' and consistent value of the
> variable. (ie: value is written by both task level and interrupt level code)
> (this is rather tricky)
>

Two solutions. The first involves direct requests for new data:

Main:
clear allow_data_in_isr
It may now either read data or write data
   If writing data, write, then set data_ready
   If reading data, read, then clear data_ready and clears main_wants_new
Set allow_data_in_isr.

The main program can specifically request the isr to provide new data
by:
clearing allow_data_in_isr
clearing data_ready
setting main_wants_new
setting allow_data_in_isr

Main responds to isr_wants_new by:
clearing allow_data_in_isr
loading data
setting data_ready
setting main_wants_new
setting allow_data_in_isr

Isr:
if allow_data_in_isr is set:
   then if main_wants_new is set:
       update data
       clear main_wants_data
       set data_ready
   endif
endif

Sometimes the isr wants to request new data from main:
set isr_wants_new
clear data_ready

It is the isr's responsibility to clear isr_wants_new
once it has gotten the requested data.

Make sure that the initialization routine initializes all
the flags properly for first-time operation, and has
proper dummy values loaded into variable(s).

**** second solution

Main and isr can each update variables whenever they have valid data.
No specific data request required.

Main:
clear allow_data_in_isr
It may now either read data or write data
   If writing data, write, then set data_ready
   If reading data, read, then clear data_ready
Set allow_data_in_isr.

Isr:
if allow_data_in_isr is set:
   update data
   set data_ready
   endif
endif

in the case of reading data, if data_ready is set, read
data and clear data_ready. No need to check allow_data_in_isr
when just reading data, as this flag is used to prevent
updating of the variable(s) by the isr during the short
time that the main routine has this flag high.

Make sure that the initialization routine initializes all
the flags properly for first-time operation, and has
proper dummy values loaded into variable(s).

Fr. Thomas McGahee

----- Original Message -----
From: Bob Ammerman <RAMMERMAN@PRODIGY.NET>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Monday, November 06, 2000 1:32 PM
Subject: [PIC]: Multibyte words and Interrupts - A challenge


> What if you need to share multibyte data between 'task' and interrupt level
> code, and you are not allowed to disable interrupts AT ALL.
>
> Given:
>
> The 2-byte variable 'shared_var'.
>
> Problem 1: We want to guarantee that interrupt level can always get a
> 'reasonably current' and consistent value of the variable as set by task
> level. (ie: value is never written by interrupt level code)
>
> Problem 2: We want to guarantee that task level can always get a 'reasonably
> current' and consistent value of the variable as set by interrupt level.
> (ie: value is never written by task level code) (hint this is rather easy)
>
> Problem 3: We want interrupt and task level both to be able to write to the
> variable, and always get a 'reasonably current' and consistent value of the
> variable. (ie: value is written by both task level and interrupt level code)
> (this is rather tricky)
>
> Criteria:
>
> Minimum extra RAM locations used.
> Minimum amount of code.
>
> Have at it!
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST
>
>
>
>

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