Interrupt driven UART

"James Beck" <jim@reallykillersystems.com> wrote in message
news:MPG.1fa1600d44355be9989d48@newsgroups.bellsouth.net...
> When I think of FIFO I think of a linear system, possibly hardware
> based, that may or may not have "wrap around" in the memory pointer
> sense.

How can you implement a FIFO without wrapping pointers around?

> Like a stack that pushes on one end and pops at the other

Which is a LIFO, not a fifo in my opinion.

> In the end I was really just trying to point out that there will be
> times when the pointers into the queue can wrap around at different
> times and make doing simple math like
> num_in_queue = queue_head - queue_tail
> might not work....

Make the operations atomic.

Meindert

In article <12jf7bg1ib8f5c8@corp.supernews.com>, 
ms@NOJUNKcustomORSPAMware.nl says...
> "James Beck" <jim@reallykillersystems.com> wrote in message
> news:MPG.1fa1600d44355be9989d48@newsgroups.bellsouth.net...
> > When I think of FIFO I think of a linear system, possibly hardware
> > based, that may or may not have "wrap around" in the memory pointer
> > sense.
> 
> How can you implement a FIFO without wrapping pointers around?
> 
> > Like a stack that pushes on one end and pops at the other
> 
> Which is a LIFO, not a fifo in my opinion.
The only difference in a LIFO and FIFO is how the data is pulled.
I guess maybe I'm not expressing myself well here.
I am speaking of how you mentally model the queue, not necessarily how 
it is physically implemented.  
> 
> > In the end I was really just trying to point out that there will be
> > times when the pointers into the queue can wrap around at different
> > times and make doing simple math like
> > num_in_queue = queue_head - queue_tail
> > might not work....
> 
> Make the operations atomic.

OK, the operations are atomic.
How does that stop the head pointer from wrapping around and pointing at 
a lower address that the tail pointer?

"James Beck" <jim@reallykillersystems.com> wrote in message
news:MPG.1fa171b7b275bf1f989d49@newsgroups.bellsouth.net...
> > > num_in_queue = queue_head - queue_tail
> > > might not work....
> >
> > Make the operations atomic.
>
> OK, the operations are atomic.
> How does that stop the head pointer from wrapping around and pointing at
> a lower address that the tail pointer?

Ah, misread that. But, if you make the buffer size a power of two, you can
simply subtract the tail from the head and AND the result with bufsize-1. I
do that all the time. Another way is to add a byte/element counter.

I must admit that I very often miss hardware support for circular buffers in
micros. All it needs is a hardware AND/OR and a smart linker that puts the
buffer at a power of 2-boundary. Very common feature in DSPs.

Meindert

In article <12jfaj2akdq5de1@corp.supernews.com>, 
ms@NOJUNKcustomORSPAMware.nl says...
> "James Beck" <jim@reallykillersystems.com> wrote in message
> news:MPG.1fa171b7b275bf1f989d49@newsgroups.bellsouth.net...
> > > > num_in_queue = queue_head - queue_tail
> > > > might not work....
> > >
> > > Make the operations atomic.
> >
> > OK, the operations are atomic.
> > How does that stop the head pointer from wrapping around and pointing at
> > a lower address that the tail pointer?
> 
> Ah, misread that. But, if you make the buffer size a power of two, you can
> simply subtract the tail from the head and AND the result with bufsize-1. I
> do that all the time. Another way is to add a byte/element counter.
> 
> I must admit that I very often miss hardware support for circular buffers in
> micros. All it needs is a hardware AND/OR and a smart linker that puts the
> buffer at a power of 2-boundary. Very common feature in DSPs.
> 
> Meindert
> 

Right, I guess we were both thinking the same thought, I just couldn't 
see exactly what you were saying and just got caught up in the 
terminology.
I could see how in a DSP it(hardware queue support) would be handy to 
store samples that need to be sent out to a codec or ones that have come 
in from conversion.

                                     Jim

On 18/10/2006 the venerable galapogos etched in runes:

> 
> John B wrote:
> > On 17/10/2006 the venerable goister@gmail.com etched in runes:
> > 
> > .
> > .
> > .
> > > So how about this pseudocode in my ISR then
> > > 
> > > if (tail+1 == head) {  // fifo overflow!
> > >   overflow_flag = 1;
> > >   // disable UART RX here and handle retransmission
> > >   junk = (unsigned char) buffer2; // clears buffer2
> > >   // enable RX here
> > > } else { // no fifo overflow!
> > >   // check parity error from status reg here
> > >   if (parity_error) {
> > >     // disable RX here and handle retransmission
> > >     junk = (unsigned char) buffer2; // clears buffer2
> > >     // enable RX here
> > >   } else {
> > >     fifo[Tail++] = (unsigned char) buffer2;
> > >     Tail &= BUFFLEN - 1; // handles wraparound
> > >   }
> > > }
> > 
> > Be careful as this code may fail in two places:
> > 
> > if(tail+1 == head)
> > 
> > will not work when 'head' is less than 'tail'. That situation will
> > arise as soon as the buffer wraps around.
> > 
> > tail &= BUFFLEN - 1;
> > 
> > will only work if BUFFLEN is a power of 2. For example it will fail
> > if BUFFLEN is 10.
> > 
> > --
> > John B
> 
> Hi John,
> 
> I don't really get you on your first point. fyi I'm adding to the tail
> of the fifo and removing from the head of the fifo. The tail naturally
> has to wrap around for an overflow to occur. For example, if head is
> say 5 and the tail wraps around back to 0 and then to 4, then this
> would indicated a fifo overflow since there are no more available
> spaces in the fifo to add to. You do bring up a good point about
> overflow though, and my tail+1 doesn't take into account of that,
> since if my tail is the sizeof of the fifo then tail+1 wouldn't wrap
> back to 0. I'll have to take care of that.

Sorry I've been away since yesterday so haven't been here until now.

The correct way top do this is to have a separate variable which is
initialised to BUFFLEN. 'BufferSpace' would be a good name. Every time
you add a character to the buffer 'BufferSpace' is incremented and when
a character is removed 'BufferSpace' is decremented. It then always
tracks the available space.

> 
> Anyway, I do realize that BUFFLEN has to be a power of 2. The idea was
> suggested by another member in an earlier post, but thanks for
> reminding me of the wonders of powers of 2 arithmetic :)

That has caught me out more than once.


-- 
John B

Meindert Sprang wrote:
> "James Beck" <jim@reallykillersystems.com> wrote in message
>
... snip ...
> 
> How can you implement a FIFO without wrapping pointers around?
> 
>> Like a stack that pushes on one end and pops at the other
                                       ^^^^^^^^^^^^^^^^^^^^^
> 
> Which is a LIFO, not a fifo in my opinion.

Notice the underlined statement above.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

John B wrote:
> On 18/10/2006 the venerable galapogos etched in runes:
> 
... snip ...
>>
>> Anyway, I do realize that BUFFLEN has to be a power of 2. The idea
>> was suggested by another member in an earlier post, but thanks for
>> reminding me of the wonders of powers of 2 arithmetic :)
> 
> That has caught me out more than once.

You don't need a power of 2.  You just need to do modulo
arithmetic.  But watch out for how your system performs that on a
negative value.  C89 and C99 are different here.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:4537D597.D3F27C8E@yahoo.com...
> Meindert Sprang wrote:
> > "James Beck" <jim@reallykillersystems.com> wrote in message
> >
> ... snip ...
> >
> > How can you implement a FIFO without wrapping pointers around?
> >
> >> Like a stack that pushes on one end and pops at the other
>                                        ^^^^^^^^^^^^^^^^^^^^^
> >
> > Which is a LIFO, not a fifo in my opinion.
>
> Notice the underlined statement above.

Oops..... :-)=)

Meindert

Another question. Is there any way an MCU can provide a clock to
another UART device? I'm asking because I'm trying to emulate ISO7816
via a regular UART, and the smart card needs a 1-5MHz clock(ideally
3.5712MHz for 9600baud) and I'm trying to reduce cost and not having a
separate osc for the card.

galapogos wrote:
> 
> Another question. Is there any way an MCU can provide a clock to
> another UART device? I'm asking because I'm trying to emulate
> ISO7816 via a regular UART, and the smart card needs a 1-5MHz
> clock(ideally 3.5712MHz for 9600baud) and I'm trying to reduce
> cost and not having a separate osc for the card.

What has this got to do with anything?  You failed to quote any
preceding material.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>