Post by thread:[PICLIST] FIFO buffer

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.

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_OUTcflatTakeThisOuTev1.net" <.....cflatKILLspam@spam@EV1.NET> writes: {Quote hidden}> 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. > > 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.

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 <PICLISTKILLspamMITVMA.MIT.EDU> From: Harold M Hallikainen <.....haroldhallikainenKILLspam.....JUNO.COM> Subject: [PIC:] Re: FIFO buffer To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU {Quote hidden}> 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 "cflatspam_OUTev1.net" <@spam@cflatKILLspamEV1.NET> > writes: > 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. > > > > 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. > ============================== Ruben Jvnsson AB Liros Elektronik Box 9124, 200 39 Malmv, Sweden TEL INT +46 40142078 FAX INT +46 40947388 KILLspamrubenKILLspampp.sbbs.se ============================== -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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" <TakeThisOuTjhulattEraseMEspam_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

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 <RemoveMEdvanhornTakeThisOuTCEDAR.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

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

> 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

> -----Original Message----- > From: Harold Hallikainen [SMTP:haroldhallikainenEraseME.....JUNO.COM] > Sent: Wednesday, September 10, 2003 5:15 PM > To: EraseMEPICLISTMITVMA.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 RemoveMEpostmasterEraseMEEraseMEbookham.com. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.