Searching \ for ' 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/index.htm?key=fifo+buffer
Search entire site for: 'FIFO buffer'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] FIFO buffer'
2001\01\14@182011 by cflat

flavicon
face
HI all,
I have a problem that I hope someone has already come across before.
I have a slave PIC (16F877@20mhz) which will be receiving data from a
master PIC (16F877@20mhz) in the system.  This data will be 2 bytes.
Once the data is received, the slave PIC will begin to parse it and
do some math, rounding, ascii conversion and then construct a
sentence using that data plus data the slave has gathered from a GPS
receiver, all used to construct a sentence to then be sent out the
serial port to a PC.  During the time that the data is being made
ready and sent out the RS-232 port I cannot lose any more data that
may be coming from the master PIC.  Therefore I have set up the
communications in the slave PIC to be interrupt driven.  Here's where
the question comes in, is there a way to set up a FIFO buffer using
registers to store the data with some sort of counter to keep track
of it.  I might get 3, 4, 5, 10 or more transmissions of the 2 byte
data from the master fairly quickly and then some time in between
which I hope will give me enough time to catch up and clear out the
FIFO before I receive more.  I know that the FIFO will at some point
have a limit and could overflow and so I would like to make it as
large as I can but if it happens then I will send some sort of
overflow message out the serial port if it should occur.  If anyone
can point me to some info on doing this I would appreciate it, I
didn't see anything in my search.  Any info/advice is greatly
appreciated.
Regards,
Charles

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


'[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



'[PIC:] FIFO buffer'
2003\09\10@045943 by Hulatt, Jon
flavicon
face
Hi All,

Has anyone ever written some code for a FIFO buffer? Can't see anything on
piclist.com

I need one about 10 bytes in size. Maybe I'll have to write it myself!!

Jon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@050606 by

picon face
Hulatt, Jon wrote:
> Has anyone ever written some code for a FIFO buffer? Can't see anything on
> piclist.com
>
> I need one about 10 bytes in size. Maybe I'll have to write it myself!!

Hi.
The development environment that Olin distributes
(for free) has this builtin complete with a number
of macros such as FIFO_DEFINE, FIFO_INIT, FIFO_PUT,
FIFO_GET and so on. If you don't want to use the complet
environment, you could maybe get a few "ideas" from reading
Olins code...

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@051019 by Alan B. Pearce

face picon face
>Has anyone ever written some code for a FIFO buffer? Can't see anything on
>piclist.com
>
>I need one about 10 bytes in size. Maybe I'll have to write it myself!!

The code is easy enough. But instead look at Olin's macros in his
development environment at http://www.embedinc.com/pic/ He has a number of
macros relating to initialising, writing and reading a FIFO.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@052306 by Thomas C. Sefranek

face picon face
I have assembly code for a FIFOs in the PIC18 series.

 *
 |  __O    Thomas C. Sefranek   spamBeGoneWA1RHPspamBeGonespamARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

> {Original Message removed}

2003\09\10@075515 by Olin Lathrop

face picon face
> Has anyone ever written some code for a FIFO buffer? Can't see anything
> on piclist.com

See my various FIFO_xxx macros near the end of STD.INS.ASPIC at
http://www.embedinc.com.  You can also seem them in use in the template
UART module, QQQ_UART.ASPIC.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@081007 by Rob Hamerling

flavicon
face
Hulatt, Jon wrote:

> Has anyone ever written some code for a FIFO buffer? Can't see anything on
> piclist.com

What do you actually mean by 'FIFO buffer'?
- software transmit buffer in PIC RAM
- hardware buffer connected to a PIC?
- supporting the FIFO buffer of a PC?
- else...
Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@121821 by Harold Hallikainen

picon face
I haven't written one for a PIC, but did it for the MC6802 years ago. It's a "circular buffer." You have an array of bytes, an input pointer (or index) and an output pointer (or index). On initialization, both are set to index 0. To put something into the buffer, store it at the location pointed to by the input pointer, then increment the index (auto-incrementing FSR is nice for this). If you ran off the end of the array, set the pointer back to the beginning of the array. The input index always points to an empty location that is to be next filled.

To pull something from the buffer, read the location pointed to by the output pointer, then increment the pointer. Again, if the increment runs you off the end of the buffer, put it back at the start.

To check to see if there's anything in the buffer, compare the input and output pointers. They are the same if the buffer is empty.

To see if the buffer is full, read the output pointer, add 1 (and if it ran off the end of the buffer, set the result back to the start of the buffer), and compare this result with the input pointer. If they are equal, the buffer is full.

Note that there is always 1 unused byte (the one right before the one pointed to by the input pointer). If this were used, you could not tell the difference between a full and empty buffer.

You should check to see if the buffer is full before putting anything in it.

For more fun, write a routine that tells you how much room is in the buffer so you can see if your new data will fit.  For even more fun, write a dynamic buffer that goes and gets more ram when needed, and releases it when it's not needed. We did this in Turbo Pascal for a system where we needed LOTS of variable sized buffers.

Harold


FCC Rules Online at http://www.hallikainen.com



-- "Hulatt, Jon" <TakeThisOuTjhulattEraseMEspamspam_OUTMONSTEREUROPE.COM> wrote:

Hi All,

Has anyone ever written some code for a FIFO buffer? Can't see anything on
piclist.com

I need one about 10 bytes in size. Maybe I'll have to write it myself!!

Jon


________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit http://www.juno.com to sign up today!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@122300 by David VanHorn

flavicon
face
>
>To check to see if there's anything in the buffer, compare the input and output pointers. They are the same if the buffer is empty.
>
>To see if the buffer is full, read the output pointer, add 1 (and if it ran off the end of the buffer, set the result back to the start of the buffer), and compare this result with the input pointer. If they are equal, the buffer is full.

when i did this, i found it simpler and faster to maintain a byte count.
put incs it, and get dec's it.
for fullness, compare to the length of the buffer.

>For even more fun, write a dynamic buffer that goes and gets more ram when needed, and releases it when it's not needed. We did this in Turbo Pascal for a system where we needed LOTS of variable sized buffers.

that, i've not tried yet.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@122714 by Olin Lathrop

face picon face
> Note that there is always 1 unused byte (the one right before the one
> pointed to by the input pointer). If this were used, you could not tell
> the difference between a full and empty buffer.

So instead of wasting the byte as unused space in the buffer, you can put
that byte to good use in the header to hold the number of data bytes
currently in the buffer.  With that information, you don't need to waste a
byte in the buffer, and knowing how much is in the buffer streamlines
other operations.  That's how the FIFO macros work that I pointed to
earlier.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@123107 by Harold Hallikainen

picon face
The counter is an EXCELLENT idea! However, instead of initializing at zero, how about initializing at the buffer length. On putting something in the buffer, decrement it. On taking something out, increment it. The counter then indicates how much room is left in the buffer. If you've got a string to stick in the buffer, you now know whether it will fit before starting to stuff it in the buffer.

Harold


FCC Rules Online at http://www.hallikainen.com



-- David VanHorn <RemoveMEdvanhornspamTakeThisOuTCEDAR.NET> wrote:


>
>To check to see if there's anything in the buffer, compare the input and output pointers. They are the same if the buffer is empty.
>
>To see if the buffer is full, read the output pointer, add 1 (and if it ran off the end of the buffer, set the result back to the start of the buffer), and compare this result with the input pointer. If they are equal, the buffer is full.

when i did this, i found it simpler and faster to maintain a byte count.
put incs it, and get dec's it.
for fullness, compare to the length of the buffer.

>For even more fun, write a dynamic buffer that goes and gets more ram when needed, and releases it when it's not needed. We did this in Turbo Pascal for a system where we needed LOTS of variable sized buffers.

that, i've not tried yet.


________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit http://www.juno.com to sign up today!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@124545 by David VanHorn

flavicon
face
At 04:29 PM 9/10/2003 +0000, Harold Hallikainen wrote:

>The counter is an EXCELLENT idea! However, instead of initializing at zero, how about initializing at the buffer length. On putting something in the buffer, decrement it. On taking something out, increment it. The counter then indicates how much room is left in the buffer. If you've got a string to stick in the buffer, you now know whether it will fit before starting to stuff it in the buffer.

never thought of that /vbg/

great idea.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@152904 by Intosh, Ph.D.

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

source= http://www.piclist.com/piclist/2003/09/10/124545a.txt?

I have posted a solution to both the FIFO and the Stack
in a high level language on my piclist page.  It should be completely
transparent how to write assembly from this.

http://www.piclist.com/techref/member/AM-vima-Y84/index.htm

Real Soon Now (RSN) I will hand compile this.  It is 1 of 2 items
that I need to produce next on my project, and it only needs to have 3-4
hours of "quality" time.  Though I will release the .asm file, I think I
can make it have sufficient quality that only the .o and .inc files are
needed.  Is the PICLIST community mostly sharing .asm files, or is anyone
doing .o+.inc releases?  The .o+.inc gives better quality, IMHO, but some
extra discipline is required.  Thoughts?

One of my consistent error patterns is to screw up the "Fencepost count" so
those of you who are adept at spotting that particular error may do us all
a favor and go hunting for them.

Some questions that I have are:
0.  Is there a better place in the PICLIST resources to publish this source?

1.  Does the community want variable size FIFOs instead of 1 fixed
size?  (that is, perhaps an 8 and a 16 in the same program).  More
generality uses more RAM, more Cycles, less ROM overall in a project.

2.  I am tinkering with "Handlers" in this code.  C programmers would
probably call this a "pointer to a procedure."  There is lively discussion
in other arenas as to whether this then becomes a complete and true "Object
oriented" solution.  I am currently grumpy with the aesthetics of managing
PCLATH in my code, but I do have a working prototype in my bit-bang UART.

Is anyone doing "Object oriented" assembly on the PIC?

3.  I would *really* like to see a few different styles of hand compiling
this into a relocatable paradigm, with the .o+.inc releases (or even
better, with only 1 .inc file that everyone uses.)


- ---
Aubrey  McIntosh
http://www.piclist.com/member/AM-vima-Y84
PIC/PICList FAQ: http://www.piclist.com


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP196zgKlSw8yssF7EQLKdACeN6qGP0yoKeYx79iFmOEL4juEPv0AoMYn
E4NHST9KSZ1YpeH4oaHZ8NNA
=vZaH
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@161233 by Olin Lathrop

face picon face
> Is the PICLIST community mostly sharing .asm files, or is
> anyone doing .o+.inc releases?  The .o+.inc gives better quality, IMHO,
> but some extra discipline is required.  Thoughts?

When I first started with PICs, I figured I'd make libraries of "standard"
routines as I created them, and package the .o files into library files so
the linker would pick whatever I referenced, just like on a real computer.

Unfortunately this didn't work.  There was too much external configuration
information per project so that any one .o file was only good for the
project it was created for.  Examples of such configuration are the
oscillator speed, size and location of the software stack, and number of
"general registers" defined.

I ended up creating my library routines at the source code level as
include files.  The include file for each project was then broken into two
parts, xxxLIB.INS.ASPIC and xxx.INS.ASPIC.  The first defines all the
generic configuration information that isn't project specific and needs to
be known by library modules.  The second contains all the project specific
declarations.  All the project specific modules include the project
include file, which includes the LIB include file.  I then have stubs for
each library routine used by a project.  The stub includes the LIB include
file only, then the generic library source routine include file.

You can see examples of this in the HAL project described at
http://www.embedinc.com/pic/hal.htm.  The only include file seen by the
generic library source modules is
http://www.embedinc.com/pic/hallib.ins.aspic.htm, and the include file
seen by the project specific modules is
http://www.embedinc.com/pic/hal.ins.aspic.htm.

> I am currently grumpy with the
> aesthetics of managing PCLATH in my code,

Take a look at my GCALL, GJUMP, and related macros in STD.INS.ASPIC at
http://www.embedinc.com/pic.  I rarely have to mess with PCLATH unless I'm
doing deliberate manipulation of the program counter, like a computed GOTO
or table lookup.

> Is anyone doing "Object oriented" assembly on the PIC?

I've done that in a few rare cases.  Object oriented structuring can be a
useful abstraction, especially when multiple people are working on a large
source project.  However, a PIC project is usually written by a single
person, and the abstraction can use up scarce runtime resources like call
stack levels.  In the end doing a good job of conventional programming
still beats anything less using any other method you can chose.  Break up
the project into modules, keep a clean master include file with all the
declarations, document the interfaces to every routine and macro, and
explain what most instructions are doing with good end of line comments.
If you do all this religiously, you'll have clean code that anyone
familiar with PICs can follow.  It will probably be less confusing because
it's not messing with program memory pointers a lot.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\11@051337 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: Harold Hallikainen [SMTP:haroldhallikainenEraseMEspam.....JUNO.COM]
> Sent: Wednesday, September 10, 2003 5:15 PM
> To:   EraseMEPICLISTspamMITVMA.MIT.EDU
> Subject:      Re: [PIC:] FIFO buffer
>
>
> Note that there is always 1 unused byte (the one right before the one
> pointed to by the input pointer). If this were used, you could not tell
> the difference between a full and empty buffer.
>
When I wrote a circular buffer in C a few years back I noticed this and it
realy bugged me.  However, with a bit of thought you can use the whole
buffer by using a simple flag to indicate if the buffer has data waiting.
On a system that is tight on RAM the saving can be worthwhile.

bit TxDataAvailable = 0;

CIRC_BUFF_ERR PutTxCircBuffer(unsigned char val)
{
       // check if there is room left in the buffer
       if( TxDataAvailable && (TxInPtr == TxOutPtr) )
               return CIRC_BUFF_FULL;
       else
               {
               // put new char into buffer
               TxCircBuff[TxInPtr++] = val;
               // wrap pointer around if end of buffer found
               if(TxInPtr >= TX_CIRC_BUFF_SIZE)
                       TxInPtr = 0;
               // set data available flag
               TxDataAvailable = 1;
               return CIRC_BUFF_OK;
               }
}

CIRC_BUFF_ERR GetTxCircBuffer(unsigned char *val)
{
       if( !TxDataAvailable )
               return CIRC_BUFF_EMPTY;
       else
               {
               // get the next char
               *val = TxCircBuff[TxOutPtr++];
               // wrap pointer around if end of buffer found
               if( TxOutPtr >= TX_CIRC_BUFF_SIZE )
                       TxOutPtr = 0;
               // clear flag if the buffer is now empty
               if( TxInPtr == TxOutPtr )
                       TxDataAvailable = 0;
               return CIRC_BUFF_OK;
               }
}

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterEraseMEspamEraseMEbookham.com.

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

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