Reply by Bob Smith April 19, 20042004-04-19
> careful about
> > exactly when you post the semaphore".
>
> I don't think in the HC12 world placement can create a problem, as long as
the semaphore is updated last, ie, when the char is actually there, the only
difference would be timing, available either this poll or the next.

Yes, that is the "care" that is required. I think you have grasped the
concept very well.

> Of course if it is interrupt driven even the placement makes no
difference.

Yes, if protected by disabled interrupts, this point is more or less moot.

In an environment where the producer and consumer are not synchronized, then
the placement becomes significant. --- Avoid computer viruses, Practice safe hex ---

-- Specializing in small, cost effective
embedded control systems --

http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith
Smith Machine Works, Inc.
9900 Lumlay Road
Richmond, VA 23236 804/745-1065
----- Original Message -----
From: "theobee00" <>
To: <>
Sent: Monday, April 19, 2004 4:50 PM
Subject: [68HC12] Re: Serial Communication > --- In , "Bob Smith" <bobsmith5@v...> wrote:
>
> How a "single pointer" ring buffer scheme would work is
> > beyond me.
>
> Something got corrupted along the way, probably by me, Sydney talked about
a single semaphore to indicate state, not a single buffer pointer.
> Nevertheless it is a concept, it would have to be a system where the
producer fils up a buffer and hence keeps a pointer, then feeds the chars
shift style into some location or other for the consumer to uh, use.
>
> Possibly might have advantages for very short buffers.
>
> > If I may be permitted to borrow the "producer" and "consumer" terms
>
> Sydney opened up a whole new world of usefull Jargon for me...
>
> careful about
> > exactly when you post the semaphore".
>
> I don't think in the HC12 world placement can create a problem, as long as
the semaphore is updated last, ie, when the char is actually there, the only
difference would be timing, available either this poll or the next.
> Of course if it is interrupt driven even the placement makes no
difference.
>
>
> Regards,
>
> Theo >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>
> --
------
> Yahoo! Groups Links
>
> a.. To


Reply by theobee00 April 19, 20042004-04-19
--- In , "Bob Smith" <bobsmith5@v...> wrote:

How a "single pointer" ring buffer scheme would work is
> beyond me.

Something got corrupted along the way, probably by me, Sydney talked about a single semaphore to indicate state, not a single buffer pointer.
Nevertheless it is a concept, it would have to be a system where the producer fils up a buffer and hence keeps a pointer, then feeds the chars shift style into some location or other for the consumer to uh, use.

Possibly might have advantages for very short buffers.

> If I may be permitted to borrow the "producer" and "consumer" terms

Sydney opened up a whole new world of usefull Jargon for me...

careful about
> exactly when you post the semaphore".

I don't think in the HC12 world placement can create a problem, as long as the semaphore is updated last, ie, when the char is actually there, the only difference would be timing, available either this poll or the next.
Of course if it is interrupt driven even the placement makes no difference. Regards,

Theo


Reply by Gary Olmstead April 19, 20042004-04-19
That's what I get for answering email on Sunday evening without looking up
the answer. But I've never used the fuzzy logic stuff.

Thanks for the clarification.
Gary Olmstead
Toucan Technology
Ventura CA

At 10:30 PM 4/18/04, you wrote:
Actually, the HC12 was the first of the Moto microcontrollers where there
*was* a possibility of interrupting an instruction, at least one of a very
few instructions. From the CPU12 reference manual

>"When an interrupt service request is recognized, the CPU responds at the
>completion of the instruction being executed. Interrupt latency varies
>according to the
>number of cycles required to complete the current instruction. Because the
>REV,
>REVW and WAV instructions can take many cycles to complete, they are
>designed so
>that they can be interrupted. Instruction execution resumes when interrupt
>execution
>is complete."
>
>So, those 3 instructions are interruptable, but the balance of the
>instructions are not.


Reply by Gary Olmstead April 19, 20042004-04-19
Bob --

I should have known that; I did work with the '332 a number of years ago.
Thanks for the clarification.

Gary Olmstead
Toucan Technology
Ventura CA At 06:04 AM 4/19/04, you wrote:
>Gary --
>
>I think your statement is just a bit too broad to stand without
>qualification.
>
>It is definitely true for the "low end" MCUs (05, 08, 11), I'm not sure
>about the HC12 or HC16, but --
>
>Interruptable instructions _do_ exist on the M68332 (CPU32) MCU family and,
>I am sure, on many of the newer MCUs that Moto has developed.


Reply by Bob Smith April 19, 20042004-04-19

< big snips >

---- Original Message -----
From: "theobee00" <>
To: <>
Sent: Monday, April 19, 2004 9:46 AM
Subject: [68HC12] Re: Serial Communication > --- In , "Bob Smith" <bobsmith5@v...> wrote:
>
> Yes that is clear, it is that I have never encountered a circular buffer
that has only one pointer, usually the read and write are quite distinct,
with only the receive interrupt driven.
> If the retrieve is interrupted it makes no real difference if end of
buffer is -1 at that time.
>

Nor have I ever encountered a "single pointer" ring buffer scheme. There
has always been a 'Head' pointer and a 'Tail' pointer to mark the boundries
of the active data. How a "single pointer" ring buffer scheme would work is
beyond me.

If I may be permitted to borrow the "producer" and "consumer" terms ---

My original premise was that the pointer update sequences do NOT need to be
atomic. Only the producer ever _updates_ the Head pointer, and only the
consumer ever _updates_ the Tail pointer so there is no conflict that needs
to be resolved.

There is one possible condition that requires some careful consideration.
It is possible that the consumer _examines_ the Head pointer to determine
the "buffer empty" condition at nearly the exact time that the producer
enters the next byte of data and _updates_ the Head pointer. This could
produce a false "buffer empty" condition if there were a collision of
events. Under normal conditions that is of no consequence as the orphaned
communications byte will be picked up and processed on the next poll and,
anyway, exactly the same condition can exist due to slight variations in
communications timing. Thus, my original caveat, "if the producer uses a
semaphore to inform the consumer that data is waiting, be very careful about
exactly when you post the semaphore".

Bob Smith

> > Now
> > update the buffer pointer with a single INC instruction which will
increment
> > the current pointer and if it wraps 256 bytes ($FF), it will overflow
and
> > wrap back to $00. Viola!
>
> Viola indeed, that's very neat, I have added it to my bag of tricks.

Even when I can't spare the RAM to create full 256 byte buffers, I always
try to make my buffers a power of two in length.

Updating the pointers then consists of:

1. Load the pointer variable.
2. Increment it.
3. AND it (always) with a mask that will strip any overflow of the power of
two and force it back to zero.
4. Store the updated pointer variable.

This is tidy and compact. It avoids the troublesome boundry conditions
requiring Greater Than, Greater Than or Equal, etc. tests, and buffer wrap
is not a special condition, the instruction sequence is always the same.

Best wishes, Bob

>
> Thanks again for the explanation. > Regards, > Theo >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>
> --
------
> Yahoo! Groups Links
>
> a.. To



Reply by theobee00 April 19, 20042004-04-19
--- In , "Bob Smith" <bobsmith5@v...> wrote:

> When I use "atomic" in this context, I am thinking of a "indivisible
> process". That 'process' can be:
>
> 1. As you describe, a single instruction which must not be interruptible.
>
> 2. A sequence of instructions which must not be interrupted.
>
> 3. A longer sequence of instructions such as an interrupt handler which
> must not be interrupted.

Thanks Bob, a very lucid explanation.
It appeared my understanding of the word Atomic was somewhat limited.

> To me the essential requirement is that you understand the concept of an
> "indivisible process".

Of course I did understand the concept of indivisible process, hard to write interrupts without that, just didn't know the word Atomic was applied to such.

> stated to be source code upward compatible from the HC11), do not have _any_
> interruptible instructions.

It appears for all intents an purposes this is so, the few exceptions do not appear to need special consideration since they are interruptable and thus inherently "Atomic":-)

> execution and initiate exception processing. Those who are masochistic
> enough to want to pursue this bizarre, and sometimes very complex, world
> should refer to the M68300 CPU32 Reference Manual, CPU32RM/AD, Section 6,
> "Exception Processing". Recovery from such "exceptions" and restarting the
> interrupted instruction can become a very challenging process.

My tiny mind has enough problems dealing with the complexities of the HC12, I do not perceive a burning need to futher my knowledge in the direction of exception processing...

> Since there is, _generally_ _speaking_, no single instruction in the low end
> MCU family that will retrieve a buffer pointer, increment it, test for end
> of buffer, and, finally, save the updated pointer, the user must write a
> 'sequence' of (usually) 4-5 instructions to perform this process. If it is
> possible that this sequence could be interrupted by an event that would
> would also try to manipulate the _same_ buffer pointer, then that sequence
> must be protected by masking interrupts during its execution which makes it
> an indivisible or "atomic" sequence.

Yes that is clear, it is that I have never encountered a circular buffer that has only one pointer, usually the read and write are quite distinct, with only the receive interrupt driven.
If the retrieve is interrupted it makes no real difference if end of buffer is -1 at that time.

> Now
> update the buffer pointer with a single INC instruction which will increment
> the current pointer and if it wraps 256 bytes ($FF), it will overflow and
> wrap back to $00. Viola!

Viola indeed, that's very neat, I have added it to my bag of tricks.

Thanks again for the explanation. Regards, Theo


Reply by Bob Smith April 19, 20042004-04-19
Ed --

Thank you for bringing these exceptions to our attention. I doubt that
these Fuzzy instructions are frequently enough used to be of great concern,
but those who use them should be forewarned.

This does raise the issue, however, of just how the CPU handles the
instruction restart sequence. From my purusal of the CPU12 Reference Manual
I am left with the very strong impression that some intermediate results are
stored somewhere in the hidden mechanisms of the cpu and then retrieved on
restart. This opens the issue of being _very_ careful not to use one of
those instructions in an interrupt hander. The results would surely be
catastrophic.

In conclusion, I would think the existence of these very special
instructions would not be of much concern to most programmers.

Best wishes, Bob Smith
--- Avoid computer viruses, Practice safe hex ---

-- Specializing in small, cost effective
embedded control systems --

http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith
Smith Machine Works, Inc.
9900 Lumlay Road
Richmond, VA 23236 804/745-1065
----- Original Message -----
From: "Ed Carryer" <>
To: <>
Sent: Monday, April 19, 2004 1:30 AM
Subject: Re: [68HC12] Re: Serial Communication > At 05:31 PM 4/18/2004 -0700, you wrote:
> >At 11:05 AM 4/17/04, you wrote:
> > >--- In , "Bob Smith" <bobsmith5@v...> wrote:
> > > > Although it seems, on first glance, that updating a circular (ring)
buffer
> > > > may need to be atomic, if you will look very carefully at how the
> > >
> > >Excuse my ignorance Bob, but I seem to miss something, "atomic" in my
mind
> > >is associated with interrupts that can occur in the middle of an
> > >instruction cycle, say a DMA event that occurs on a clock boundary
thereby
> > >leaving the current instruction partially completed.
> > >
> > >Does something like this occur in the Motorola devices?
> >
> >
> >No, Motorola processors never break into the middle of any instruction
for
> >any reason. 68HC12s don't have DMA.
>
> Actually, the HC12 was the first of the Moto microcontrollers where there
*was* a possibility of interrupting an instruction, at least one of a very
few instructions. From the CPU12 reference manual
>
> "When an interrupt service request is recognized, the CPU responds at the
> completion of the instruction being executed. Interrupt latency varies
according to the
> number of cycles required to complete the current instruction. Because the
REV,
> REVW and WAV instructions can take many cycles to complete, they are
designed so
> that they can be interrupted. Instruction execution resumes when interrupt
execution
> is complete."
>
> So, those 3 instructions are interruptable, but the balance of the
instructions are not.
>
> ed
> -- > --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>
> --
------
> Yahoo! Groups Links
>
> a.. To


Reply by Bob Smith April 19, 20042004-04-19
Gary --

I think your statement is just a bit too broad to stand without
qualification.

It is definitely true for the "low end" MCUs (05, 08, 11), I'm not sure
about the HC12 or HC16, but --

Interruptable instructions _do_ exist on the M68332 (CPU32) MCU family and,
I am sure, on many of the newer MCUs that Moto has developed. Bob Smith --- Avoid computer viruses, Practice safe hex ---

-- Specializing in small, cost effective
embedded control systems --

http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith
Smith Machine Works, Inc.
9900 Lumlay Road
Richmond, VA 23236 804/745-1065
----- Original Message -----
From: "Gary Olmstead" <>
To: <>
Sent: Sunday, April 18, 2004 8:31 PM
Subject: Re: [68HC12] Re: Serial Communication > At 11:05 AM 4/17/04, you wrote:
> >--- In , "Bob Smith" <bobsmith5@v...> wrote:
> > > Although it seems, on first glance, that updating a circular (ring)
buffer
> > > may need to be atomic, if you will look very carefully at how the
> >
> >Excuse my ignorance Bob, but I seem to miss something, "atomic" in my
mind
> >is associated with interrupts that can occur in the middle of an
> >instruction cycle, say a DMA event that occurs on a clock boundary
thereby
> >leaving the current instruction partially completed.
> >
> >Does something like this occur in the Motorola devices? > No, Motorola processors never break into the middle of any instruction for
> any reason. 68HC12s don't have DMA.
>
> Gary Olmstead
> Toucan Technology
> Ventura CA >
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
> --
------
> Yahoo! Groups Links
>
> a.. To



Reply by Bob Smith April 19, 20042004-04-19

> --- In , "Bob Smith" <bobsmith5@v...> wrote:
> > Although it seems, on first glance, that updating a circular (ring)
buffer
> > may need to be atomic, if you will look very carefully at how the
>
> Excuse my ignorance Bob, but I seem to miss something, "atomic" in my mind
is associated with interrupts that can occur in the middle of an instruction
cycle, say a DMA event that occurs on a clock boundary thereby leaving the
current instruction partially completed.
>
> Does something like this occur in the Motorola devices?
>
> Regards,
>
> Theo
>

Theo --

Before addressing your question, we need to re-establish the context of this
thread. It is gotten a bit "over-snipped".

From the original posting on the topic by Sydney Faria
--

"I also just ran into a need for something like SCI using ints and was
thinking of doing something like setting up a routine to send one char via
SCI_isr and the receiver would be based on receiving a char and putting it
into a circular buffer. Accessing the circular buffer with a pointer and
storing into the buffer would have to be atomic so using tpa and tap to save
CCR would be necessary when adjusting the PUT and GET pointers is concerned.
Valvano's book (University of Texas site) covers this subject very well." At the risk of starting a contentious debate involving hair splitting over
the many meanings and uses of the word "atomic" I will describe my thinking.

When I use "atomic" in this context, I am thinking of a "indivisible
process". That 'process' can be:

1. As you describe, a single instruction which must not be interruptible.

2. A sequence of instructions which must not be interrupted.

3. A longer sequence of instructions such as an interrupt handler which
must not be interrupted. In my experience the application of the term "atomic" has been very loose
with regard to the above categories and I will not argue which one, if any
of them, is correct. I use and interpret the term interchangeably in all
three contexts.
To me the essential requirement is that you understand the concept of an
"indivisible process".

As a direct answer to your question, I assert that I have used the term
"atomic", in this context, in the same manner as the author of the original
post.
That usage fits Category 2 of those stated above.

To further answer your question --

A Type 1 process (above) can only occur on so called Read-Modify-Write
instructions and then only on CPU's which permit some instructions to be
interrupted during execution before their processing is complete. To the
best of my knowledge, the low end Motorola MCUs such as the HC05_08 family,
the HC11, family, and _probably_ the HC12 family as well (since the HC12 is
stated to be source code upward compatible from the HC11), do not have _any_
interruptible instructions. In these MCU's, interrupts only occur _between_
instructions (more accurately, during the instruction pre-fetch phase).
Once instruction fetch has begun (I-phase), any interrupts which are
recognized by the MCU hardware are held pending and are only recognized
during the pre-fetch phase of the _next_ instruction.
Thus, for this class MCU, it is important that the user recognize the RMW
class instructions as they can be used to fetch a semaphore, modify it, and
update it all in one indivisible sequence that does not have to protected by
disabling interrupts. The story is not so neat when one
grows beyond the low end class of Motorola MCUs however. When you get to
the larger MCUs such as the MC68332 (CPU32) family, for example, you begin
to encounter certain instructions that can, in fact, be interrupted during
execution and initiate exception processing. Those who are masochistic
enough to want to pursue this bizarre, and sometimes very complex, world
should refer to the M68300 CPU32 Reference Manual, CPU32RM/AD, Section 6,
"Exception Processing". Recovery from such "exceptions" and restarting the
interrupted instruction can become a very challenging process.

With regard to Category 2, above, covering brief sequences of instructions
which must be implemented as an "atomic" (or indivisible) process, consider
the management of the head and tail pointers in a circular buffer scheme.
Since there is, _generally_ _speaking_, no single instruction in the low end
MCU family that will retrieve a buffer pointer, increment it, test for end
of buffer, and, finally, save the updated pointer, the user must write a
'sequence' of (usually) 4-5 instructions to perform this process. If it is
possible that this sequence could be interrupted by an event that would
would also try to manipulate the _same_ buffer pointer, then that sequence
must be protected by masking interrupts during its execution which makes it
an indivisible or "atomic" sequence.

Side note -- Actually, with the Motorola "low end MCU's" where there is
always an INC (increment eight bit memory location) instruction this whole
mess can be
neatly sidestepped _if_ you have sufficient RAM resources. Make your ring
buffers 256 bytes long and the buffer pointers eight bit variables. Now
update the buffer pointer with a single INC instruction which will increment
the current pointer and if it wraps 256 bytes ($FF), it will overflow and
wrap back to $00. Viola!

Category 3, above is merely an extension of the above discussion since the
whole ISR normally runs disabled and is, therefore, by definition, an
indivisible or "atomic" process.

Best wishes, Bob Smith --- Avoid computer viruses, Practice safe hex ---

-- Specializing in small, cost effective
embedded control systems --

http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith
Smith Machine Works, Inc.
9900 Lumlay Road
Richmond, VA 23236 804/745-1065
----- Original Message -----
From: "theobee00" <>
To: <>
Sent: Saturday, April 17, 2004 2:05 PM
Subject: [68HC12] Re: Serial Communication > --- In , "Bob Smith" <bobsmith5@v...> wrote:
> > Although it seems, on first glance, that updating a circular (ring)
buffer
> > may need to be atomic, if you will look very carefully at how the
>
> Excuse my ignorance Bob, but I seem to miss something, "atomic" in my mind
is associated with interrupts that can occur in the middle of an instruction
cycle, say a DMA event that occurs on a clock boundary thereby leaving the
current instruction partially completed.
>
> Does something like this occur in the Motorola devices?
>
> Regards,
>
> Theo >
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>
> --
------
> Yahoo! Groups Links
>
> a.. To



Reply by theobee00 April 19, 20042004-04-19
--- In , Gary Olmstead <garyolmstead@e...> wrote:

> >Although with circular buffers I would have thought the read and write are
> >independent, i.e. the producer only needs to know free space, and the
> >consumer if char is available. > Normally yes, but if I read it right, he has one variable to handle both
> "in" and "out".

Shees, that would be doing it the hard way, leaves no leaway at all.

Cheers,

Theo