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----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Harold M Hallikainen Sent: Monday, January 15, 2001 12:48 PM To: PICLIST@MITVMA.MIT.EDU Subject: [PIC:] Re: FIFO buffer 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 "cflat@ev1.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: http://dl.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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.