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

What is the baud rate of the serial data you wish to receive on the PIC? There are several registers that have to be correctly configured to communicate at a specific baud rate wit a given Fosc frequency. Provide more details and your configuration code and possibly myself or others could lead you in the right direction.

Stephen D. Barnes

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.

--
Regards,
Stephen D. Barnes

d r

As a matter of referring to concrete implementation, I'm trying to read the byte according to what's described in Figure 6 in

K0duQzM5NVdGa1E9PQ

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.

Ok, I've had a look at the data sheet you referenced as well as the app note on the TI site. The USART module in the PIC is not going to do the trick(as far as I can tell). You will need to read the data from the 3705A from an input pin on the PIC in a similar fashion to the Dallas 1-wire communication scheme. In all the documentaion on the 3705A, I have not seen any info on the formatting of the data you will read from the device other than it is NRZ (non return to zero). At this point, I don't see how I can help with this one (not your fault), although I tried.

--
Regards,
Stephen D. Barnes

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

ld

or

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:

bytewise (least significant bit first) to

start bit (high) and one stop bit

mode control register

*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.

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:

8

ould

d or

bytewise (least significant bit first) to

), one start bit (high) and one stop bit

f the mode control register

y

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?

bytewise (least significant bit first) to

start bit (high) and one stop bit

the mode control register

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.

bytewise (least significant bit first) to

one start bit (high) and one stop bit

the mode control register

This is how I rolled my own, ~1983, conveyed from pencil to CAD in

1995:

...Jim Thompson

--
| James E.Thompson, P.E.                           |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
With all this hope and change, all you need is a dab of mayonaisse
and you\'ll have a tasty lunch on which you will choke to death.

IC

h 15.8

e would

bad or

der

.

ta bytewise (least significant bit first) to

5 %), one start bit (high) and one stop bit

t of the mode control register

r.

ou

.

any

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?

would

or

bytewise (least significant bit first) to

one start bit (high) and one stop bit

the mode control register

That's my opinion.

However the PIC data sheet should make this clear.

Missed that one after reading the manual!

--
Regards,
Stephen D. Barnes