Searching \ for '[PIC] Selecting an appropriate crystal for UART an' 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/devices.htm?key=pic
Search entire site for: 'Selecting an appropriate crystal for UART an'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Selecting an appropriate crystal for UART an'
2010\07\21@132511 by V G

picon face
Hi all,

I'm currently working on a project for the university which involves
interfacing several PIC microcontrollers (dsPIC33FJ128GP802) to a PC
via MODBUS RTU over RS485. Since the microcontrollers will be
controlling temperature and humidity, they will be subject to
temperature and humidity fluctuations. I would imagine that a quartz
crystal would be advantageous in this case due to it's stability.

I am thinking of running the RS485 line at 9600 bits/s. I am
interested in maintaining a *stable* bus, it doesn't need to be
particularity fast. Reliability is the highest priority.

I used a simple program that calculates PIC UART configuration
register values based on the clock frequency and desired bit rate. I
selected various common frequencies such as 16 MHz, 20 MHz, and so on,
but all of them resulted in the program calculating a non-zero error
percentage value (0.16% at 20 MHz and 9600 bits/s). A screenshot of
the program can be viewed here:
http://img249.imageshack.us/img249/8761/screenshotno.png

Is this non-zero error value acceptable? Will it cause reliability
issues? Does it need to be avoided, and if so, how?

The second question is, does anyone know of a good MODBUS stack for
the PIC? I will most likely be using the C30 compiler for the
dsPIC33FJ128GP802. I would also like to use UART RX interrupts to
handle the protocol, but DMA is a possibility too.

2010\07\21@135055 by Bob Axtell

face picon face
RS485 is a very reliable method; I used a casino bus at 57,600bps over a
long distance (150 m +).
Use the addressable feature of the PIC UART, so that everybody on the
bus only has to listen to
the address rather than the message body as well.

--Bob A

V G wrote:
{Quote hidden}

2010\07\21@140238 by Bob Blick

face
flavicon
face

On Wed, 21 Jul 2010 13:24:47 -0400, "V G" said:

I like the shiny new moniker :)

{Quote hidden}

It's not a problem for communication, up to about .5% error is
acceptable.

You can use 19.6608 MHz crystals if you want perfect timing. That is a
standard value.

Cheerful regards,

Bob

--
http://www.fastmail.fm - The way an email service should be

2010\07\21@142150 by peter green

flavicon
face
V G wrote:
{Quote hidden}

The pic will try to sample in the middle of each bit period. The
transmitter and receiver resynronise every byte and a byte is roughly 10
bits (exactly how many depends on your exact setup). To be less than
half a clock cycle out after 10 bits the receiver clock must be less
than 5% different from the transmitter clock. In reality you want things
a bit better than that to allow for things like inaccracies in the
synchronisation (due to their nature of being locked to potentially out
of step source clocks they can never synchronise perfectly)

0.16% is more than good enough.

As bob has pointed out if you really want spot on serial baud rates you
can get crystals that are designed to be nice multiples of standard
serial baud rates. The downside is they tend to not be nice multiples of
anything else ;)
> The second question is, does anyone know of a good MODBUS stack for
> the PIC? I will most likely be using the C30 compiler for the
> dsPIC33FJ128GP802. I would also like to use UART RX interrupts to
> handle the protocol, but DMA is a possibility too.
>  

2010\07\21@144500 by Olin Lathrop

face picon face
V G wrote:
> I used a simple program that calculates PIC UART configuration
> register values based on the clock frequency and desired bit rate. I
> selected various common frequencies such as 16 MHz, 20 MHz, and so on,
> but all of them resulted in the program calculating a non-zero error
> percentage value (0.16% at 20 MHz and 9600 bits/s). A screenshot of
> the program can be viewed here:
> http://img249.imageshack.us/img249/8761/screenshotno.png
>
> Is this non-zero error value acceptable?

Of course some amount of error is always acceptable.  There is no such thing
as zero error in cases like this.  Even if the nominal crystal frequency can
be divided down exactly to get the desired baud rate, you still have crystal
error.

So the real question is how much error is acceptable.  There are 9 1/2 bit
times from the start of a character to the middle of the last bit, assuming
8 data bits, no parity bit, and 1 stop bit.  Ideally you have +- 1/2 a bit
time wiggle room in sampling a bit in its center.  1/2 / 9.5 = 5.26%.  Since
that's the guaranteed to fail limit, you don't want to be close to it.  Half
that, or 1/4 bit time in the middle of the last bit it 2.63% error.  That's
OK if you know the other end is right on.  If both ends are off by 2.63%,
then you're back to the guaranteed to fail limit.  If you need a consistant
spec for all nodes, then half again that, or +-1.32%, guarantees that the
total error stays within 1/4 bit in the middle of the last bit.

Usually we try to be a little better than that because stuff happens and you
want some margin.  The general rule of thumb is try to keep the baud rate
mismatch to 2% or below.  That means 1% per end unless you know the other
end to be better than that.  Your 0.16% error is of no consequence.

2010\07\21@151127 by Isaac Marino Bavaresco

flavicon
face
Em 21/7/2010 15:21, peter green escreveu:
> As bob has pointed out if you really want spot on serial baud rates you
> can get crystals that are designed to be nice multiples of standard
> serial baud rates. The downside is they tend to not be nice multiples of
> anything else ;)

I like to use crystals multiple of 3.6864MHz (3.6864, 7.3728, 11.0592,
14.7456 and 18.432).
They are all standard commercial values and allow for exact division for
every usual baud rate.
The 18.432MHz is particularly a good choice for PICs, because it is near
the maximum the PICs accept and also can be divided to give a nice 1KHz
interrupt tick rate.

For PIC18s this series is not that good if you want to extract the
maximum  performance, because with the 4x PLL the maximum clock you can
achieve is 29.4912MHz.

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\21@154855 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> For PIC18s this series is not that good if you want to extract the
> maximum  performance, because with the 4x PLL the maximum clock you
> can achieve is 29.4912MHz.

So use a 10MHz crystal with 4x PLL resulting in 40MHz Fosc.  At that input
speed to the baud rate generator and with the high speed mode, you can hit
the common baud rates accurately enough anyway.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\07\21@175051 by Byron Jeff

flavicon
face
On Wed, Jul 21, 2010 at 01:24:47PM -0400, V G wrote:
{Quote hidden}

Ansyncronous I/O resyncronizes with each charater. So in terms of error,
it's only required that the drift isn't more than a bit length for a single
character. Typically serial interfaces will sample the bit near the center
of the bit cell. So as long as the error does not cause the sampling to
drift into another cell, some error is fine.

0.16% is negligable. It will not cause any problems.

BAJ

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