Searching \ for '[PIC:] Re: FIFO buffer' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Re: FIFO buffer'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Re: FIFO buffer'
2001\01\14@185211 by Harold M Hallikainen

picon face
       Not sure if this is what you're looking for, but I've set up FIFOs using
a "circular buffer." It involves an array of ram with an input pointer
and an output pointer. The input pointer points to the next byte to be
filled with incoming data. The output pointer points to the next byte to
be output. The output pointer chases the input pointer around the array
of bytes. When you receive a byte, put it in the location pointed to by
the input pointer. When you're ready to pull a byte out of the buffer,
see if the output pointer points to the same location as the input
pointer. If so, the buffer is empty. Otherwise, read the byte pointed to
by the output pointer, then increment the output pointer. With both
pointers, if you run off the top of the buffer area, reset it to the
bottom of the buffer area. Finally, if the input pointer catches up with
the output pointer, the buffer is full. I think it's easiest to leave one
byte of the buffer empty. That is, prior to putting something into the
buffer, see if the increment would make you land on the output pointer.
If so, don't do it! Say the buffer is full. This leaves the one byte not
used, but avoids the problem of both pointers pointing to the same
location and your not knowing whether the buffer is empty or full. I
guess a couple flags could be set and reset as appropriate to indicate
empty and full.
       Another fun function to write is one that returns how much is in the
buffer, and how much space remains. You don't want to start putting a
packet into the buffer if the whole thing won't fit.
       Finally, in systems with lots of buffers, it's fun to dynamically
allocate chunks of memory for the buffers. As a buffer fills, you get
another chunk and keep a pointer to where that chunk is. As stuff is read
out of the chunk and it is not needed any more, it's released to the
buffer pool. Probably not likely in a small PIC project...

Harold


On Sun, 14 Jan 2001 17:17:36 +0000 "spam_OUTcflatTakeThisOuTspamev1.net" <.....cflatKILLspamspam@spam@EV1.NET>
writes:
{Quote hidden}

FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\14@194648 by Andrew Quinn

flavicon
face
I use a similar concept to hold incoming DTMF commands and found that
storing the available bytes remaining is useful.

Before adding a byte to the queue check that bytes available is not zero.

After adding decf the bytes remaining.

If bytes available = queue length then there is nothing to be extracted from
the queue.

After extracting incf the bytes remaining.

Maintain two pointers for nextin and nextout that wrap back to the begining
when you get to the end of the queue.


In my application the DTMF command may optionally be followed by parameters.
The number of parameters vary by command.  I have functions that check if
there is any further work to do by reading the byte at nextin, and comparing
the number of bytes in the queue with the number required for the command to
be complete at which point the bytes are extracted and processed.

Hope this helps.

Regards..... Andrew

{Original Message removed}

2001\01\15@063433 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
I use circular FIFO buffers all the time, for serial RX and TX, for
LCD displays, for EEPROMS - just about everywhere there is a need to
serially transmit or receive data at a rate which is very slow
compared to the processor capacity or where I want to preassemble the
characters to transmitt before actually transmitting them.

I have two routines to handle these FIFOS, putchar and getchar. Every
FIFO has two bytes connected to them, the FIFO handle. The first byte
in this handle contains a pointer to the start location of the first
character in the buffer (that is, the next character to pull out when
reading the buffer - not the start of the FIFO) and the second byte
contains how many characters the buffer currently holds. Where I need
to have several FIFOs of different size I use a third byte that holds
the size of the FIFO. The size of the FIFO is always a multiple of 8
(usually 8, 16 or 32 bytes) and I have almost always the same size of
all FIFOs in a program.

This way it's easy to check if the buffer is empty (the second byte
in the handle is zero) or to clear the buffer (clear the second byte
in the handle).

putchar takes two arguments, the buffer handle and the character to
put in the FIFO. I could return a value or a flag saying the buffer
is full but it doesn't - se below.

getchar takes one argument, a pointer to the buffer handle and
returns one flag and one value, the flag tells if the buffer is empty
and the value is the first buffer character.

I don't use FSR as the pointer argument for these routines (pointer
to the handle) since I have found that I often use the FSR at the
same time for other purposes when I put or get characters to the
FIFOs. Instead I use W as the pointer and a tempregister for the
character. putchar and getchar is responsible to load the FSR and
before exiting restoring the FSR. This way I don't have to worry
about saving the FSR in my main program.

I also don't care about checking for buffer full when I put
characters to the FIFO since I have found it easier to logically make
sure that the buffer never gets full in my programs (set the FIFO
large enough to hold the largest commandstrings for RX and
replystrings for TX for example) and just keeps overwriting old input
data with new.

Regards Ruben



Date sent:              Sun, 14 Jan 2001 15:47:58 -0800
Send reply to:          pic microcontroller discussion list
<PICLISTspamKILLspamMITVMA.MIT.EDU>
From:                   Harold M Hallikainen <.....haroldhallikainenKILLspamspam.....JUNO.COM>
Subject:                [PIC:] Re: FIFO buffer
To:                     EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU

{Quote hidden}

==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
KILLspamrubenKILLspamspampp.sbbs.se
==============================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...