Searching \ for 'UART Q:' 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=
Search entire site for: 'UART Q:'.

Truncated match.
PICList Thread
'UART Q:'
1996\11\14@155914 by Luckjiff Glen

flavicon
face
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_OUTluckjiffTakeThisOuTspamcae.wisc.edu

1996\11\14@175735 by Les Troyer

flavicon
face
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
> .....luckjiffKILLspamspam@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 ljtspamKILLspamnfuel.com

Ad Hoc, Ad Loc, Quid Pro Quo; So Little Time SO Much To Know.
  -Jeromy Hillery Dillery Boo, PHD, MS and Q

1996\11\14@182415 by Wireless Scientific

flavicon
face
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
>> .....luckjiffKILLspamspam.....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_OUTspamTakeThisOuTnet-magic.net

Or you might know me as
Dr. Craig Hollabaugh
Analog Microelectronics, Georgia Institute of Technology
hollaspamspam_OUTmonique.adgrp.gatech.edu

or

Dr. Craig Hollabaugh
Aerospace Department, University of Texas, Austin
@spam@hollaKILLspamspamcfdlab.ae.utexas.edu

1996\11\14@195851 by Arvid Jedlicka

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

1996\11\14@234032 by Giles L. Honeycutt
flavicon
face
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}

1996\11\15@001649 by tjaart

flavicon
face
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             |
|______________________________________________________________|

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