--- 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 |
Serial Communication
Started by ●April 15, 2004
Reply by ●April 19, 20042004-04-19
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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 |