Exact match. Not showing close matches.
'[PIC] Selecting an appropriate crystal for UART an'
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:
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.
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.
V G wrote:
On Wed, 21 Jul 2010 13:24:47 -0400, "V G" said:
I like the shiny new moniker :)
It's not a problem for communication, up to about .5% error is
You can use 19.6608 MHz crystals if you want perfect timing. That is a
http://www.fastmail.fm - The way an email service should be
|V G wrote:
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.
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:
> 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
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.
Isaac Marino Bavaresco
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.
Fale com seus amigos de graça com o novo Yahoo! Messenger
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.
On Wed, Jul 21, 2010 at 01:24:47PM -0400, V G wrote:
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.
More... (looser matching)
- Last day of these posts
- In 2010
, 2011 only
- New search...