How accurate/tolerant is the PIC USART clock rate?

Take a look into your micros datasheet. It is all in there.

HTH Wolfgang

I had the datasheet downloaded and open when I posted this.

I haven't found much useful there:

"The data on the RXx pin (either RC7/RX1/DT1 or RG2/ RX2/DT2) is sampled three times by a majority detect circuit to determine if a high or a low level is present at the pin."

"The data recovery block is actually a high-speed shifter operating at 16 times the baud rate, whereas the main receive serial shifter operates at the bit rate or at FOSC. This mode would typically be used in RS-232 systems"

That's about it.

And the information in the timing diagrams is limited to setup and hold times on the I/O pins.

As usual, that depends. The principle factor is the actual clock and its tolerance. If possible most designers aim for a 16x clock. This allows a start bit to be confirmed after 8 clocks, at roughly the middle of a bit period. (If not confirmed, the start bit is ignored as noise, answering Q1). From then on the UART samples the line every 16 clock times, resulting in a sample at the nominal middle of a bit time. If tolerances put that sample time outside the actual bit time, things will fail. Once the stop bit is received, again at nominal middle of a bit period, the complete byte (or whatever) is confirmed and shipped and the system rearms to hunt a new start bit.

Note that any even clock divisor automatically puts a bias on the sampling time.

Draw a few timing diagrams showing start detection delay and clock tolerance effects and all will rapidly be clear. IIRC the net effect is that a 3% 16x clock tolerance is likely to be fatal to the normal start + 8 bits + 1 stop bit configuration. Remember both ends can have tolerances, so effects are doubled.

I understand the process, I am looking for details on the timing (which sample clocks are critical, what error bits are set for which condition, etc.

The little quote from the data sheet says majority of three samples, but doesn't say which 3.

I'm looking at a spec that always sends a Break (more 0's than a legal byte) followed by a 55 to "train" the clock frequency.

On 18 Aug 2006 18:49:12 -0700, " snipped-for-privacy@hotmail.com" wrote in comp.arch.embedded:

Every 16x clock UART I've ever seen that included that spec on the data sheet sampled on the 7th, 8th, and 9th clock edge, the nominal bit center and one clock on either side. The majority logic provides some noise immunity against noise signals less than 1 to 1.5 of the

That's a little unusual. Usually auto baud detection routines start with an idle line, and require that the first character sent have an odd numeric value (such as ASCII carriage return, 13 decimal, 0d hex).

Firmware monitors the pin and counts the number of clock cycles of the one low (at the logic level on the pin) start bit between the high of the idle line and the high of the least significant data bit.

But the principle's the same the way you describe.

It's LIN, Local Interconnect Network. Spec avaialbel on consortium website

Fine. Thats all you must know.

Obvioulsy, you should ensure that your last transmitted bit is not more than a half bit time away.

But, believe me, please do yourself a favour and use the correct clock frequency.

HTH Wolfgang

That implies about a 5% tolerance, at most, right?

I agree. You run the risk that the other guy is going to be off by the maximum amount in the opposite direction, and then communication won't work.

Realistically, though, as I understand it, all this implies that 1% accuracy of baud rate is fine, and it's usually possible to do a lot better than that.

That is not my problem. I intend to use the PIC USART as expected. My questions were about its capabilites to connect effectively with a source I do not control. There appears to be very little technical data available on the PIC website aboiut the guts of the USART.

... snip ...

Then you might indulge in some experiments. A worst case would be some sort of pattern when the last tranmitted bit is opposite to the stop bit. You can connect the PIC USART to a test UART, and supply that UART with a continuous stream of the worst cast pattern. UARTs generally have an independent clock input pin, so all you need do is vary that frequency about the nominal until errors appear. Measure that frequency. That will give you an accurate picture of the tolerance available, but not the noise rejection.

In fact, you should be able to make the PIC itself generate the test clock. That will keep it locked to the actual PIC frequency. This, of course, will require that that clock is considerably lower than the main PIC clock, which should be no problem.