Post by thread:[PICLIST] 16F84 serial buffering more than 62 byte

Hello all, I am an advanced PIC programmer that knows PIC assembly language well. I have this little problem that someone may be able to help with. I have an application where I am using a 16F84 to receive and send 9600 baud serial data from 2 different sources using RB0 and RB7 on the pic. I am using 6 of the 68 General purpose registers (from 0CH to 11H) to control my program, the rest (62 registers) are used as a buffer for the data. I get the data from one of the ports (eg RB0), load it byte by byte into the registers beginning at 12H, process them, then send them back out of the other port (RB7), then go back and listen at the first (RB0) port for data. The problem I have is that I have some data streams that consist of 72 bytes of serial data, so I am missing 10 bytes of data (due to lack of buffer registers). My program works fine for data streams of less than 62 bytes. I have tried using the EEPROM as temporary storage, but the write time is to slow to load bytes into as they come in at 9600 baud. I have read the 16F84 data sheet and page 6 says that there are "greater than 116 bytes of general purpose RAM.", but I cant find them ! I know that there are other people doing a similar thing with 72 bytes of data as I have seen it operating, so it must be able to be done. can any one help me???.... I would really appreciate it. Thanks, Phil. -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Phil, Sorry, there are only 68 bytes of RAM on a 'F84. The reference in the data sheet to 'more than 116 bytes' is to the architectural arrangement of multiple banking which is shared by many of the 16C PICs. Without multiple banks there would only be 128 (ie: 2^7) bytes of address space, minus 12 bytes of SFR's gives 116 bytes of RAM maximum (architecturally). For another 18 pin PIC with more room you might try: the flash-based PIC16F627 (which is marked as 'future product' in the Q3 linecard, so good luck getting them). or one of the following non-flash parts: PIC16C554 (80 bytes of RAM) PIC16C558 (128 bytes of RAM) PIC16C620 (80 bytes of RAM) PIC16C620A (96 bytes of RAM) etc. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) {Original Message removed}

{Quote hidden}> -----Original Message----- > From: Phil [SMTP:.....pdelKILLspam@spam@SHOAL.NET.AU] > Sent: Thursday, November 02, 2000 11:26 AM > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: 16F84 serial buffering more than 62 bytes > > Hello all, > > I am an advanced PIC programmer that knows PIC assembly language well. I > have this little problem that someone may be able to help with. > > I have an application where I am using a 16F84 to receive and send 9600 > baud serial data from 2 different sources using RB0 and RB7 on the pic. I > am using 6 of the 68 General purpose registers (from 0CH to 11H) to > control > my program, the rest (62 registers) are used as a buffer for the data. I > get the data from one of the ports (eg RB0), load it byte by byte into the > registers beginning at 12H, process them, then send them back out of the > other port (RB7), then go back and listen at the first (RB0) port for > data. > > The problem I have is that I have some data streams that consist of 72 > bytes of serial data, so I am missing 10 bytes of data (due to lack of > buffer registers). My program works fine for data streams of less than 62 > bytes. I have tried using the EEPROM as temporary storage, but the write > time is to slow to load bytes into as they come in at 9600 baud. > > I have read the 16F84 data sheet and page 6 says that there are "greater > than 116 bytes of general > purpose RAM.", but I cant find them ! > > I know that there are other people doing a similar thing with 72 bytes of > data as I have seen it operating, so it must be able to be done. > > can any one help me???.... I would really appreciate it. > > Thanks, > > Phil. > I don't think anyone can help you find the extra space, there are only 68 bytes of general purpose RAM in the 16F84. The registers in the second bank are mapped to the first bank. I can't find any reference to "116 bytes of general purpose RAM" in my datasheet. Are you sure you have the most up to date copy? IIRC Philips do a 256 byte serial SRAM which may be fast enough for your needs? Mike -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

The 'f84 does not have the RAM you need, even if you use some special function registers as general-purpose registers. You have a few options here: 1) Maximize use of internal RAM a) Compress incoming data (What data is coming in and out? Are there known bytes such as start and stop codes you can assume? Perhaps many bytes in a row are the same can can be run-length encoded. Any repreating sequences?) b) Use fewer registers for your code(If youcan run on no registers, and pick up four SFRs, then you've got your 72 bytes ;-) c) Start sending the data out right after you start receiving it (I would look at this the most closely. It may require you to re-write a major portion of your code, but it's not difficult, just tedious. Is there a reason to hold a complete 'packet' before sending it out?) 2) Use external ram a) Static ram chips can be had for little, but require more pins b) Fast eeprom or flash is not an option (not enough cycles to failure) 3) Use a different chip a) Develop it on a larger flash chip ('f8xx) and then put it on a smaller OTP chip when done b) Develop it on the 'f84 and move it to a larger OTP chip If you're a hardware person, options 2 and 3 might look better to you. If you're a software person option one can yield some very nice results. Any of the above will take about the same amount of time and work (minus the time required to get parts you might not have) -Adam Phil wrote: {Quote hidden}> > Hello all, > > I am an advanced PIC programmer that knows PIC assembly language well. I > have this little problem that someone may be able to help with. > > I have an application where I am using a 16F84 to receive and send 9600 > baud serial data from 2 different sources using RB0 and RB7 on the pic. I > am using 6 of the 68 General purpose registers (from 0CH to 11H) to control > my program, the rest (62 registers) are used as a buffer for the data. I > get the data from one of the ports (eg RB0), load it byte by byte into the > registers beginning at 12H, process them, then send them back out of the > other port (RB7), then go back and listen at the first (RB0) port for data. > > The problem I have is that I have some data streams that consist of 72 > bytes of serial data, so I am missing 10 bytes of data (due to lack of > buffer registers). My program works fine for data streams of less than 62 > bytes. I have tried using the EEPROM as temporary storage, but the write > time is to slow to load bytes into as they come in at 9600 baud. > > I have read the 16F84 data sheet and page 6 says that there are "greater > than 116 bytes of general > purpose RAM.", but I cant find them ! > > I know that there are other people doing a similar thing with 72 bytes of > data as I have seen it operating, so it must be able to be done. > > can any one help me???.... I would really appreciate it. > > Thanks, > > Phil. > > -- > http://www.piclist.com hint: To leave the PICList > EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

Is the data real random or is there regular patterns to it? How about a huffman (not sure if that is spelled right) encoding scheme? Easy to implement and if certain byte values occur more than others it would be real easy to pick up those 10 missing bytes. Of course, if the data is real random, then it would become a case of it working for some of the messages, but there could be no guarantee for all. Brett Bob Ammerman wrote: > Another thought: > > If your message is 7-bit ascii you can use the high order bit of each group > of 7 bytes to store an 8th character. > > Bob Ammerman > RAm Systems > (contract development of high performance, high function, low-level > software) > > {Original Message removed}

----- Original Message ----- From: Brett Testerman <@spam@btest1KILLspamNEWSGUY.COM> To: <KILLspamPICLISTKILLspamMITVMA.MIT.EDU> Sent: Thursday, November 02, 2000 10:32 PM Subject: Re: [PIC]: 16F84 serial buffering more than 62 bytes > Is the data real random or is there regular patterns to it? How about a huffman > (not sure if that is spelled right) encoding scheme? Easy to implement and if > certain byte values occur more than others it would be real easy to pick up > those 10 missing bytes. > > Of course, if the data is real random, then it would become a case of it > working for some of the messages, but there could be no guarantee for all. > > Brett > Unfortunately just about every compression scheme, except perhaps run-length encoding, tends to require some pretty big data structures (at least in PIC terms) to store the compressor/decompressor state. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads