> On 2005-05-17, Neil Kurzman <nsk@mail.asb.com> wrote:
>
> > I did not quite get a yes or no.
>
> Gee. Maybe there is no "yes or no" answer.
>
> --
> Grant Edwards grante Yow! Put FIVE DOZEN red
> at GIRDLES in each CIRCULAR
> visi.com OPENING!!
I hate when that happens.
Reply by Neil Kurzman●May 18, 20052005-05-18
Frieder Ferlemann wrote:
> Neil Kurzman schrieb:
> > I did not quite get a yes or no. I am using this on a PIC and 8051.
> > The Keil C example had interrupt disabled, so I did not look at it in detail. I will
> > look to see if it can be done.
> > I an not a big fan of disabled interrupts. I messes up the latency of the other
> > interrupts.
> >
>
> An example for a buffer feeding routine without disabled interrupts
> for the 8051 is given in section 3.12 "Inline Assembler Code" of
> http://sdcc.sourceforge.net/doc/sdccman.pdf
>
> Greetings,
> Frieder
Thanks I will look.
Reply by Grant Edwards●May 17, 20052005-05-17
On 2005-05-17, Neil Kurzman <nsk@mail.asb.com> wrote:
> I did not quite get a yes or no.
Gee. Maybe there is no "yes or no" answer.
--
Grant Edwards grante Yow! Put FIVE DOZEN red
at GIRDLES in each CIRCULAR
visi.com OPENING!!
Reply by Frieder Ferlemann●May 17, 20052005-05-17
Neil Kurzman schrieb:
> I did not quite get a yes or no. I am using this on a PIC and 8051.
> The Keil C example had interrupt disabled, so I did not look at it in detail. I will
> look to see if it can be done.
> I an not a big fan of disabled interrupts. I messes up the latency of the other
> interrupts.
>
An example for a buffer feeding routine without disabled interrupts
for the 8051 is given in section 3.12 "Inline Assembler Code" of
http://sdcc.sourceforge.net/doc/sdccman.pdf
Greetings,
Frieder
Reply by Neil Kurzman●May 17, 20052005-05-17
I did not quite get a yes or no. I am using this on a PIC and 8051.
The Keil C example had interrupt disabled, so I did not look at it in detail. I will
look to see if it can be done.
I an not a big fan of disabled interrupts. I messes up the latency of the other
interrupts.
Reply by Ian Bell●May 16, 20052005-05-16
Grzegorz Mazur wrote:
>
> The 51 core disables the interrupts while servicing an interrupt. It's
> THAT simple. Assuming you don't use different priorities for the
> interrupts refering to the same resource.
The 8051 core disables interrupts OF THE SAME PRIORITY while servicing an
interrupt. An interrupt of a higher priority can interrupt one of a lower
priority. In the old days it was still simple because the original 8051 had
only two interrupt priority levels. However, some modern derivatives have
more.
Ian
Reply by Grzegorz Mazur●May 16, 20052005-05-16
Neil Kurzman wrote:
>>My own experience follows the teaching of one of my mentors in that one very
>>rarely (if ever) needs to disable interrupts. In the 8051 world, use
>>interrupt priority, short service routines and amenable data structures. In all
>>of our 8051 communication products, I can not think of one that runs with
>>interrupts disabled. Being an assembly language dinosaur helps here.
>
>
> OK so how do you do a ring buffer without disabling interrupts during RX read , or a
> Tx write?
> The Interrupt could hit during that time. The Keil C sample disables RI during that
> time.
The 51 core disables the interrupts while servicing an interrupt. It's
THAT simple. Assuming you don't use different priorities for the
interrupts refering to the same resource.
Reply by Lanarcam●May 16, 20052005-05-16
CBFalconer wrote:
> Ian Bell wrote:
> >
> ... snip ...
> >
> > I certainly hope you would never recommend a potential infinite
> > loop inside an ISR. Your ISR code really should produce an error
> > if the buffer is full.
>
> Of course not. That was just to illustrate the cause of the
> problems. You have all sorts of mechanisms, including signal/wait,
> monitors, etc. available.
Or some counter is incremented each time a new item is placed in
the buffer. The sender increments the counter that the receiver
reads and stores in a local variable. On the next cycle
the receiver checks the counter against its local variable
in order to see if new items were added to the buffer.
The receiver reads the counter but never writes to it, thus it
needs not to be protected by a semaphore or the like.
The receiver then reads the data and increments another counter.
The sender will check that counter in order to verify that the
buffer is not full.
This works well if you have a periodic activation of the receiver
or if the sender activates the receiver whenever the counter is
incremented.
The counter must be incremented once the data has been put to
the buffer not before. Then if the sender is interrupted by
the receiver after the data were written but before the counter
was incremented, the receiver will not retrieve them since
the counter will be equal to the local value.
Reply by CBFalconer●May 16, 20052005-05-16
Ian Bell wrote:
>
... snip ...
>
> I certainly hope you would never recommend a potential infinite
> loop inside an ISR. Your ISR code really should produce an error
> if the buffer is full.
>
> 1: read input ptr
> <--- interrupt updates input ptr
> read output ptr
> compare ptrs
> if empty goto 1
>
> The only problem here is that you get the "empty" indication, even
> though there would be a value available at the time of the compare
> instruction. In a polled system like this, the pending value would be
> extracted at the next cycle anyway.
>
Depends, if the read of each pointer is not atomic i.e. requires more than
one instruction, then it can be interrupted part way through the read, its
value altered then the read completed. This is the well known shared data
problem.
Ian