Searching \ for '[PIC:] Serial port tolerances' 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/microchip/ios.htm?key=serial
Search entire site for: 'Serial port tolerances'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Serial port tolerances'
2004\06\22@151446 by Anthony Toft

flavicon
face
I have a starting project that is going to be basically a front panel processor
It will talk to the PC via rs232 (possibly using the USART) and to a gps module
using serial CMOS. I am not hurting for pins and I am thinking of bitbanging the
gps communications and _possibly_ the PC too. The gps will run at 9600 baud, the
pc I haven't decided, but I am thinking 19200 (there is a lot more data on that
line)

The main question I have is, the PIC documentation has lots of tables giving
crystal speeds and some form of constant (I don't have the book in front of me)
that gives a baudrate with a bit of error, the errors vary from 0% to several
percent. How much can I get away with? I'd like to run the PIC as fast as
possible as it is also going to be controlling a VFD and some buttons.

Thanks

Anthony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@152525 by Wouter van Ooijen

face picon face
> How much can I get away with? I'd like to run the
> PIC as fast as
> possible as it is also going to be controlling a VFD and some buttons.

IIRC 5% is the absolute maximum total error, I would say 1% maximum
baudrate error at the PIC side.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@154617 by David VanHorn

flavicon
face
>
>The main question I have is, the PIC documentation has lots of tables giving
>crystal speeds and some form of constant (I don't have the book in front of me)
>that gives a baudrate with a bit of error, the errors vary from 0% to several
>percent. How much can I get away with? I'd like to run the PIC as fast as
>possible as it is also going to be controlling a VFD and some buttons.

Figure the other guy gets at least half the error budget.

Otherwise, pick a crystal like 14.765 MHz that's an even baud rate divisor.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@170953 by Tom

flavicon
face
At 02:11 PM 6/22/04 -0400, you wrote:
>that gives a baudrate with a bit of error, the errors vary from 0% to several
>percent. How much can I get away with?

Anthony,

First check the archives - this one has been around forever.

Suppose you have one start bit, 8 data bits and one stop bit. Ten bits to
send before the system can re-sync.  This is asynchronous comms, right?
Different uarts sample differently but for the sake of the discussion,
assume one that samples at 50% bit time. Thus, you must accumulate less
than 50% of a bit time of error after 10 bits.

So if you are 5% off from perfect baud rate, after 10 bits go by, you will
be right at half a bit off and the last bit will likely be sampled wrong.
If you are running 2.5% fast and the receiver is 2.5% slow, same thing.
Some uarts sample differently and will be more or less tolerant than this.

1% error 'should' work anywhere. 2% is starting to eat up the error budget.
If there will be more than this, please tell us what product it goes in so
we can avoid purchasing it.

Many clever ways have been thought up to deal with this.  One method lets
the PC start comms with some sync characters.  You measure these and bit
bang a software uart padding as required to get acceptable bit times.  Lots
easier to just get the right crystal...

Tom

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@191233 by Jinx

face picon face
> the PIC documentation has lots of tables giving crystal speeds
> and some form of constant (I don't have the book in front of me)
> that gives a baudrate with a bit of error, the errors vary from 0%
> to several percent. How much can I get away with? I'd like to run
> the PIC as fast as possible as it is also going to be controlling a
> VFD and some buttons.

That's a terrible table and I've never liked it

I'd suggest 19.6608 for a 20MHz part and 39.3216MHz for a 40MHz
part (39.3216 is 9.8304 with the *4 multiplier). Using these you'll be
very close to the speed limit of the PIC and have 0% RS232 error

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@221204 by Byron A Jeff

face picon face
On Tue, Jun 22, 2004 at 02:07:34PM -0700, Tom wrote:
> At 02:11 PM 6/22/04 -0400, you wrote:
> Many clever ways have been thought up to deal with this.  One method lets
> the PC start comms with some sync characters.  You measure these and bit
> bang a software uart padding as required to get acceptable bit times.


One that I had thought about briefly was to do the software sampling using the
standard RxD pin as an ordinary digital input. Then after getting the sample
rate, then set up the bitrate generator to closely match it as possible then
switch on the hardware USART.

> Lots easier to just get the right crystal...

True. However with the halfway decently specified tolerances on the
internal nanowatt (tm?) oscillators in the newer PICs it would be useful
to be able to run the part at 8 Mhz, use the hardware USART, and recover the
two I/O pins that the crystal would require.

Just a thought.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@221751 by Tom

flavicon
face
At 10:12 PM 6/22/2004 -0400, you wrote:
>> Lots easier to just get the right crystal...
>
>True. However with the halfway decently specified tolerances on the
>internal nanowatt (tm?) oscillators in the newer PICs it would be useful
>to be able to run the part at 8 Mhz, use the hardware USART, and recover the
>two I/O pins that the crystal would require.
>
>Just a thought.
>
>BAJ

A very good one, Byron.

One should read the specs carefully and see what can be done with the part
as is. And if it works, then it's "good enough".  The new pics are getting
better in this regard - and with a proliferation of 8 pin and 6 pin sot
parts, not having to use a crystal/resonator is a good thing.

Tom

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\23@005616 by Byron A Jeff

face picon face
On Tue, Jun 22, 2004 at 07:16:36PM -0700, Tom wrote:
> At 10:12 PM 6/22/2004 -0400, you wrote:
> >> Lots easier to just get the right crystal...
> >
> >True. However with the halfway decently specified tolerances on the
> >internal nanowatt (tm?) oscillators in the newer PICs it would be useful
> >to be able to run the part at 8 Mhz, use the hardware USART, and recover the
> >two I/O pins that the crystal would require.
> >
> >Just a thought.
> >
> >BAJ
>
> A very good one, Byron.

Thanks,

>
> One should read the specs carefully and see what can be done with the part
> as is. And if it works, then it's "good enough".  The new pics are getting
> better in this regard - and with a proliferation of 8 pin and 6 pin sot
> parts, not having to use a crystal/resonator is a good thing.

The problem is that over the entire temp range of the part, it's pretty
much impossible to meet the spec. Let's take a 5 second glance at the 16F88
datasheet... Hmmm, it's really not all that bad.

+/- 2% at 25C
+/- 5% at -10C to 85C
+/- 10% at -40C to 85C

So it should in fact work fine at room temp. However if the room gets a bit
cold or hot and you drift in the 3-4% range of error along with whatever
error the other device may have, you'll start getting errors.

But software resyncing the clocks when frame errors or receive errors occur
can help the situation. It's really just adjusting the bitrate clock to follow
the drive in the INTRC.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@085817 by Bob Ammerman

picon face
Self-training bit rates are a good idea, but what can happen when ends of
the link are using this technique?

Bob Ammerman
RAm Systems


{Original Message removed}

2004\06\23@093417 by Sergio Masci

picon face
----- Original Message -----
From: Bob Ammerman <.....rammermanKILLspamspam@spam@VERIZON.NET>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Wednesday, June 23, 2004 1:57 PM
Subject: Re: [PIC:] Serial port tolerances


> Self-training bit rates are a good idea, but what can happen when ends of
> the link are using this technique?
>
> Bob Ammerman
> RAm Systems
>

If you adjust the bit rate by half the difference of what you think the bit rate
is and the bit rate you are actually using, both ends will home in on each
other. I used a similar approach many years ago to synchronise the software
clocks on two machines. The two machines took very little time to lock onto each
others clocks and use a reliable time stamp for sending messages back and forth
to each other.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@104350 by Bob Ammerman

picon face
Should read:  ...when both ends of link...


----- Original Message -----
From: "Bob Ammerman" <EraseMErammermanspam_OUTspamTakeThisOuTVERIZON.NET>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Wednesday, June 23, 2004 8:57 AM
Subject: Re: [PIC:] Serial port tolerances


> Self-training bit rates are a good idea, but what can happen when ends of
> the link are using this technique?
>
> Bob Ammerman
> RAm Systems
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

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