USART configuration on a PIC18F4680 using an external crystal of 32kHz

[ssylee]

I'm trying to implement the USART on a PIC18F4680 running on an
external crystal to read a SCI signal that ranges from 15.3 to 15.8
kHz. I know that using an external crystal of over 2 MHz or more would
induce more significant errors in the USART module divider. How bad or
much more suitable is using a 32 kHz crystal instead? Thanks.

 

[ssylee]

On a clearer note from my last message, I am hoping to have the PIC
receive the data between the rates of 15300 and 15800, even though
they may not be standard baud rates. Think you can make any
suggestions based on these rates? Thanks.

 

[ssylee]

Again, what is the correct baud rate of the serial device
sending the data (Published in it's documentation possibly)?
This info is critical to your success. The baud rate of the
PIC will have to be set at one specific value. It will not
be able to receive a serial data stream that varies by 500 baud.

As a matter of referring to concrete implementation, I'm trying to
read the byte according to what's described in Figure 6 in
http://www.yousendit.com/transfer.php?action=batch_status&batch_id=U0d6K0duQzM5NVdGa1E9PQ

On the table described on page 14 of the datasheet, the period of each
bit in the byte sequence is ranging from 63 to 65 us. This translates
to 15300 to 15800 that I have suggested on my very first post of the
thread. If I aim at a figure midway, I'm aiming at a baud rate of
15550, but if the baud rate is within these two ranges, it should be
fine according to the datasheet (that's I interpret it anyway).

Hope this helps.

 

[ssylee]

UARTs can usually tolerate several per cent of baud rate to clock
mismatch. If he aims for around 15.55Kbaud, the extremes will be under
2% off.

Most UARTs need an 8x or 16x clock, and usually have additional
scalers.

John

Thanks for your advices on this. I guess this chip isn't as easy to
work with as I thought. I will reorganize the information about the
RFID tag that I'm trying to read and then ask for suggestions about
modules that are easier to use in order to read the tag data. Thanks.

 

[IanM]

Thanks for your advices on this. I guess this chip isn't as easy to
work with as I thought. I will reorganize the information about the
RFID tag that I'm trying to read and then ask for suggestions about
modules that are easier to use in order to read the tag data. Thanks.

RTFM! Page 4 paragraph 2:

The SCI encoder uses an 8-bit shift register to send the received data bytewise (least significant bit first) to
the microcontroller with a transmission rate of 15.625 kbaud (± 1.5 %), one start bit (high) and one stop bit
(low), but no parity bit (asynchronous mode indicated by the SYNC bit of the mode control register
permanently low).

*most* UARTS that are properly designed to sample near the centre of
each bit time can handle at least +/- 1/4 bit time error in a character.
For a ten bit character thats near enough 2.5% and you can be sure
that you'll start getting errors somewhere before 5%. Your incoming
signal is +/- 1.5% @ 15.625 KBaud. Only way I see a problem is if you
are using the PIC internal oscillator and *not* trimming its frequency.

If its running on a crystal as you propose, *and* you are not doing any
other async. serial communication, spreadsheet the Microchip USART
divider calculation and pick an easily obtained crystal frequency that
gives less than 1% error at 15.625 KBaud.

 

[ssylee]

RTFM! Page 4 paragraph 2:


*most* UARTS that are properly designed to sample near the centre of
each bit time can handle at least +/- 1/4 bit time error in a character.
  For a ten bit character thats near enough 2.5% and you can be sure
that you'll start getting errors somewhere before 5%.  Your incoming
signal is +/- 1.5% @ 15.625 KBaud.  Only way I see a problem is if you
are using the PIC internal oscillator and *not* trimming its frequency.

If its running on a crystal as you propose,  *and* you are not doing any
other async. serial communication, spreadsheet the Microchip USART
divider calculation and pick an easily obtained crystal frequency that
gives less than 1% error at  15.625 KBaud.

Thanks for pointing out the second paragraph of page 5. Totally missed
that when I went through the manual. I am planning to use an external
oscillator of a 32 kHz crystal. If I were to use the suggested 15.625
kbaud frequency, I think I would get within the acceptable range by
dividing the crystal frequency by 2, which deviates from the suggested
frequency by 2.4%. Would you suggest using a crystal that is even
closer to the 15.625 kbaud frequency?

 

[Raveninghorde]

Thanks for pointing out the second paragraph of page 5. Totally missed
that when I went through the manual. I am planning to use an external
oscillator of a 32 kHz crystal. If I were to use the suggested 15.625
kbaud frequency, I think I would get within the acceptable range by
dividing the crystal frequency by 2, which deviates from the suggested
frequency by 2.4%. Would you suggest using a crystal that is even
closer to the 15.625 kbaud frequency?

You usually need a crystal at least 16 times the data rate to receive
accurately. The UART can only sample the middle of the data bit by
being much faster.

IMHO, and without checking the PIC data sheet, with a 32kHz clock and
15.625kHz data rate you will get aliasing which will cause a problem.

 

[ssylee]

You usually need a crystal at least 16 times the data rate to receive
accurately. The UART can only sample the middle of the data bit by
being much faster.

IMHO, and without checking the PIC data sheet, with a 32kHz clock and
15.625kHz data rate you will get aliasing which will cause a problem.

From what you're saying, I would need at least a 256 kHz crystal to
avoid aliasing issues while small enough so that I don't get the large
errors from the divider as described in the PIC datasheet?

 

[Raveninghorde]

From what you're saying, I would need at least a 256 kHz crystal to
avoid aliasing issues while small enough so that I don't get the large
errors from the divider as described in the PIC datasheet?

That's my opinion.

However the PIC data sheet should make this clear.