Post by thread:UART Q:

hi. I'm connecting two 65 PICs with USARTS using RS232 in asyncronous mode with a MAX232A on each end. The PICs use RC oscillators. Problem is that if the internal clocks are off substantially (40kHz) due to component tolerences say the data gets corrupted. I could modify the SPRG value to get the baud rates close, but what is a good algorithm to do this. Also, can anyone suggest a simple protocol data transfer. Thanks for your time. Glen Luckjiff spam_OUTluckjiffTakeThisOuTcae.wisc.edu

According to Luckjiff Glen: > > hi. I'm connecting two 65 PICs with USARTS using RS232 > in asyncronous mode with a MAX232A on each end. The PICs use > RC oscillators. Problem is that if the internal clocks are off > substantially (40kHz) due to component tolerences say > the data gets corrupted. I could modify the SPRG value to > get the baud rates close, but what is a good algorithm to do > this. Also, can anyone suggest a simple protocol data transfer. > Thanks for your time. > Glen Luckjiff > .....luckjiffKILLspam@spam@cae.wisc.edu > Since your in control of both sides of the link use an extra pin (or two) to externally(self) clock the beast. This has the side effect of speeding up the communication to what ever the slowest side can handle-- just make sure the slower (ie busier) PIC is the one supplying the clock. -- Les Troyer Sr. Analyst Siemens Power Corp 2101 Horn Rapids Rd. Richland, Wa. 99352-0130 Voice (509) 375-8695 Fax (509) 375-8940 Operator (509) 375-8100 email ljtKILLspamnfuel.com Ad Hoc, Ad Loc, Quid Pro Quo; So Little Time SO Much To Know. -Jeromy Hillery Dillery Boo, PHD, MS and Q

At 2:47 PM 11/14/96, Les Troyer wrote: >According to Luckjiff Glen: >> >> hi. I'm connecting two 65 PICs with USARTS using RS232 >> in asyncronous mode with a MAX232A on each end. The PICs use >> RC oscillators. Problem is that if the internal clocks are off >> substantially (40kHz) due to component tolerences say >> the data gets corrupted. I could modify the SPRG value to >> get the baud rates close, but what is a good algorithm to do >> this. Also, can anyone suggest a simple protocol data transfer. >> Thanks for your time. >> Glen Luckjiff >> .....luckjiffKILLspam.....cae.wisc.edu >> > >Since your in control of both sides of the link use an extra pin (or two) to >externally(self) clock the beast. This has the side effect of speeding up the >communication to what ever the slowest side can handle-- just make sure the >slower (ie busier) PIC is the one supplying the clock. if you don't want to go sync, you could send a "start" byte with every packet like a 0x0F or 0xFF or 0x00. Then have the receiving PIC sample the RX line and run a counter to determine the byte length time. From that, adjust the SPRG value. craig ________________________________________________________ Dr. Craig Hollabaugh Wireless Scientific, Inc. 1890 South 14th Street Building 100, Suite 105 Amelia Island, FL 32034 904 261 6977 904 261 2129 fax EraseMEwscispam_OUTTakeThisOuTnet-magic.net Or you might know me as Dr. Craig Hollabaugh Analog Microelectronics, Georgia Institute of Technology hollaspam_OUTmonique.adgrp.gatech.edu or Dr. Craig Hollabaugh Aerospace Department, University of Texas, Austin @spam@hollaKILLspamcfdlab.ae.utexas.edu

At 02:57 PM 11/14/96 -0600, Glen Luckjiff wrote: [snip] >Also, can anyone suggest a simple protocol data transfer. [snip] I would also be interested in a simple "inter-pic" data transfer protocol. My needs suggest something capable of 75 to 150 bytes of data in a packet, which eliminates the CAN solutions. Thanks, Arvid Jedlicka

I have read 2 other replies, and knowing how my projects are.. Far apart(distance), and only wanting to use 3 wires, RX, TX, and GND, I am sure you don't care for the extra output clock idea. Oh the second idea, that is a interesting idea, to sample the byte length, and then operate at that speed. Well, I am sure that would work, but for any fast BPS rates, I would say you would get much to high a percentage of error. I am working on a project that does not use the uart, so I will give an example of solving the problem without using the uart. I can correct my timing after each byte if I send about 3 or 4 bits length of stop bit (typically hi for 1.5 bits is a normal stop bit) The receiving end will not start getting a byte till it sees the start bit (a low), this will only give you 9 bits for timing errors to show up. I know I have a lot of slop in my bit-bang functions, but at 9600bps, I can talk nonstop with no errors. As I am not using the uart, I might not of given you any usable advice. Good luck. Giles L. Honeycutt Luckjiff Glen wrote: {Quote hidden}> > hi. I'm connecting two 65 PICs with USARTS using RS232 > in asyncronous mode with a MAX232A on each end. The PICs use > RC oscillators. Problem is that if the internal clocks are off > substantially (40kHz) due to component tolerences say > the data gets corrupted. I could modify the SPRG value to > get the baud rates close, but what is a good algorithm to do > this. Also, can anyone suggest a simple protocol data transfer. > Thanks for your time. > Glen Luckjiff > KILLspamluckjiffKILLspamcae.wisc.edu

IIC is VERY fast and level triggered, which makes it very stable. Furthermore, your master supplies the clock, so you don't need accurate timing. You only need two wires (and GND)and the protocol is very easy. You can still use the RS232 levels if you want. -- Friendly Regards Tjaart van der Walt ______________________________________________________________ | Another sun-deprived R&D Engineer slaving away in a dungeon | |WASP International GSM vehicle tracking and datacomm solutions| | +27-(0)11-622-8686 | http://wasp.co.za | |______________________________________________________________|