The idea of disabling interrupts

In article <4753d96a$0$10915$e4fe514c@dreader19.news.xs4all.nl>, usenet+
5@c-scape.nl says...

-----

For the OP:  if figuring out a clever way to mux your LEDs is the
point of the project, continue as you are.  If the point is
to program a system to accept input and generate output, you
might consider one of the serial graphics LCD displays  such
as those on sale at www.sparkfun.com.


Mark Borgerson

Arlet Ottens wrote:
> CBFalconer wrote:
>> Arlet Ottens wrote:
>>> Ted wrote:
>>>
>> ... snip ...
>>>> This is the situation that semaphores were designed to avoid.
>>>> Unless you have a processor with atomic read-modify-write a
>>>> simple flag is not going to work for two or more tasks.
>>> It can be made to work if only one task is writing the flag and
>>> the other one is reading it. A typical application is a ping-ping
>>> buffer between a task and an ISR.
>>>
>>> In this design, there are two buffers, and a flag. The flag is
>>> written by the task, and read by the ISR.
>>>
>>> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
>>> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
>>>
>>> When the task's read buffer is empty, it toggles the flag. The
>>> task doesn't need to disable interrupts in this case.
>>
>> This requires that the process of making that decision can inhibit
>> the operation of the 'ISR'.
> 
> What can go wrong if it doesn't ?
> 
>> To me 'ISR' implies an interrupt
>> routine, so that inhibition implies disabling interrupts.  As I see
>> it everything can fail uncontrollably when the input rate exceeds
>> the output rate.  Which also implies that the interval between
>> input events must be large enough that the output task can empty
>> the current buffer.
> 
> Yes, ISR = interrupt service routine.
> 
> My assumption is that the buffer assigned to the ISR can store
> multiple input events. The system needs to be designed to guarantee
> that the task can empty its buffer, and switch the buffers, before
> the ISR fills up its buffer. Of course, any other kind of system
> needs to make similar guarantees.
> 
> The advantage of using ping pong buffers is that it makes it easier
> to handle a buffer full of incoming events in a burst, without
> having to worry that the buffer will be modified in the meantime.

Yes, BUT while the reader is emptying the buffer, the writer is
still filling it. So the system has to run on that buffer
continuously until it is totally empty.  Until then the condition
for buffer change doesn't occur.  When it does, why change buffers,
when the current one is already empty?

-- 
 Chuck F (cbfalconer at maineline dot net)
   <http://cbfalconer.home.att.net>
   Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
> Arlet Ottens wrote:
>> CBFalconer wrote:
>>> Arlet Ottens wrote:
>>>> Ted wrote:
>>>>
>>> ... snip ...
>>>>> This is the situation that semaphores were designed to avoid.
>>>>> Unless you have a processor with atomic read-modify-write a
>>>>> simple flag is not going to work for two or more tasks.
>>>> It can be made to work if only one task is writing the flag and
>>>> the other one is reading it. A typical application is a ping-ping
>>>> buffer between a task and an ISR.
>>>>
>>>> In this design, there are two buffers, and a flag. The flag is
>>>> written by the task, and read by the ISR.
>>>>
>>>> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
>>>> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
>>>>
>>>> When the task's read buffer is empty, it toggles the flag. The
>>>> task doesn't need to disable interrupts in this case.
>>> This requires that the process of making that decision can inhibit
>>> the operation of the 'ISR'.
>> What can go wrong if it doesn't ?
>>
>>> To me 'ISR' implies an interrupt
>>> routine, so that inhibition implies disabling interrupts.  As I see
>>> it everything can fail uncontrollably when the input rate exceeds
>>> the output rate.  Which also implies that the interval between
>>> input events must be large enough that the output task can empty
>>> the current buffer.
>> Yes, ISR = interrupt service routine.
>>
>> My assumption is that the buffer assigned to the ISR can store
>> multiple input events. The system needs to be designed to guarantee
>> that the task can empty its buffer, and switch the buffers, before
>> the ISR fills up its buffer. Of course, any other kind of system
>> needs to make similar guarantees.
>>
>> The advantage of using ping pong buffers is that it makes it easier
>> to handle a buffer full of incoming events in a burst, without
>> having to worry that the buffer will be modified in the meantime.
> 
> Yes, BUT while the reader is emptying the buffer, the writer is
> still filling it. So the system has to run on that buffer
> continuously until it is totally empty.  Until then the condition
> for buffer change doesn't occur.  When it does, why change buffers,
> when the current one is already empty?

The purpose of buffer switching is to avoid shared access to a 
particular buffer. Sure, compared to a regular FIFO, the ping-pong 
buffer scheme uses more memory. Worst case, you'll need twice the memory 
that a FIFO would use. Because of that, it's certainly not useful in all 
circumstances.

However, unlike data in a FIFO, we always know exactly where the data 
starts, and that there is a certain contiguous block of it. This can be 
very useful if incoming data is received by DMA, or if it needs to be 
handled in bursts for optimal throughput. It is also easy to ensure the 
buffers are aligned on some boundary, if that is necessary for fast 
access or to deal with hardware limitations.

To get back in context of the thread... it is also possible to implement 
a regular FIFO between an ISR and a task that can work without disabling 
interrupts. Which one is more suitable depends completely on the problem 
at hand.

On Dec 3, 11:48 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> Arlet Ottens wrote:
> > CBFalconer wrote:
> >> Arlet Ottens wrote:
> >>> Ted wrote:
>
> >> ... snip ...
> >>>> This is the situation that semaphores were designed to avoid.
> >>>> Unless you have a processor with atomic read-modify-write a
> >>>> simple flag is not going to work for two or more tasks.
> >>> It can be made to work if only one task is writing the flag and
> >>> the other one is reading it. A typical application is a ping-ping
> >>> buffer between a task and an ISR.
>
> >>> In this design, there are two buffers, and a flag. The flag is
> >>> written by the task, and read by the ISR.
>
> >>> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
> >>> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
>
> >>> When the task's read buffer is empty, it toggles the flag. The
> >>> task doesn't need to disable interrupts in this case.
>
> >> This requires that the process of making that decision can inhibit
> >> the operation of the 'ISR'.
>
> > What can go wrong if it doesn't ?
>
> >> To me 'ISR' implies an interrupt
> >> routine, so that inhibition implies disabling interrupts.  As I see
> >> it everything can fail uncontrollably when the input rate exceeds
> >> the output rate.  Which also implies that the interval between
> >> input events must be large enough that the output task can empty
> >> the current buffer.
>
> > Yes, ISR = interrupt service routine.
>
> > My assumption is that the buffer assigned to the ISR can store
> > multiple input events. The system needs to be designed to guarantee
> > that the task can empty its buffer, and switch the buffers, before
> > the ISR fills up its buffer. Of course, any other kind of system
> > needs to make similar guarantees.
>
> > The advantage of using ping pong buffers is that it makes it easier
> > to handle a buffer full of incoming events in a burst, without
> > having to worry that the buffer will be modified in the meantime.
>
> Yes, BUT while the reader is emptying the buffer, the writer is
> still filling it. So the system has to run on that buffer
> continuously until it is totally empty.  Until then the condition
> for buffer change doesn't occur.  When it does, why change buffers,
> when the current one is already empty?
>

This Doublebuffering scheme to ping-pong between two receive buffers
is really wonderful,
That is,       Receive data into Buffer A and operate on Buffer B.
                  Then, receive on Buffer B and operate on Buffer A.

Karthik Balaguru