I am looking at a design which uses a PIC18F8520 whose USART is
connected to a PC serial port running at a fairly high data rate.  I am
also looking at the design of a serial port instantiated in an FPGA
connected to the same data stream in an RS-485 network.  Having to deal
with the internal details of the FPGA "USART" makes me wonder about the
internal details of the PIC USART.  FOr instance:

How long or short can or must the start bit be to be accepted?

Where in a bit time and for how many samples does the USART compare to
determine whether a bit is 1 or 0?

How much tolerance does the PIC USART have to bit-timing discrepancies
on the RX side?

Can anyone provide any answers to these questions, or point to a good
document or FAQ that deals with them?

Hi,

p...@hotmail.com wrote:
> Where in a bit time and for how many samples does the USART compare to
> determine whether a bit is 1 or 0?
> 
> How much tolerance does the PIC USART have to bit-timing discrepancies
> on the RX side?
> 
> Can anyone provide any answers to these questions, or point to a good
> document or FAQ that deals with them?

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

HTH
Wolfgang

-- 
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at

Wolfgang Mahringer wrote:
> Hi,
>
> p...@hotmail.com wrote:
> > Where in a bit time and for how many samples does the USART compare to
> > determine whether a bit is 1 or 0?
> >
> > How much tolerance does the PIC USART have to bit-timing discrepancies
> > on the RX side?
> >
> > Can anyone provide any answers to these questions, or point to a good
> > document or FAQ that deals with them?
>
> Take a look into your micros datasheet.
> It is all in there.
> www.microchip.com

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

http://ww1.microchip.com/downloads/en/DeviceDoc/39609b.pdf

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.

"p...@hotmail.com" wrote:
> 
> I am looking at a design which uses a PIC18F8520 whose USART is
> connected to a PC serial port running at a fairly high data rate. 
> I am also looking at the design of a serial port instantiated in
> an FPGA connected to the same data stream in an RS-485 network. 
> Having to deal with the internal details of the FPGA "USART" makes
> me wonder about the internal details of the PIC USART.  FOr
> instance:
> 
> How long or short can or must the start bit be to be accepted?
> 
> Where in a bit time and for how many samples does the USART
> compare to determine whether a bit is 1 or 0?
> 
> How much tolerance does the PIC USART have to bit-timing
> discrepancies on the RX side?
> 
> Can anyone provide any answers to these questions, or point to a
> good document or FAQ that deals with them?

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.

-- 
"The power of the Executive to cast a man into prison without
 formulating any charge known to the law, and particularly to
 deny him the judgement of his peers, is in the highest degree
 odious and is the foundation of all totalitarian government
 whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

CBFalconer wrote:
> 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.

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.

> 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'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, "p...@hotmail.com"
<p...@hotmail.com> wrote in comp.arch.embedded:

> 
> CBFalconer wrote:
> > 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.
> 
> 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.

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
16x clock cycles.

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

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.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack Klein wrote:
> On 18 Aug 2006 18:49:12 -0700, "p...@hotmail.com"
> <p...@hotmail.com> wrote in comp.arch.embedded:
>
> >
> > CBFalconer wrote:
> > > 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.
> >
> > 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.
>
> 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
> 16x clock cycles.
>
> > > 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'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.
>
> 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

http://www.lin-subbus.org/

Hi,

p...@hotmail.com wrote:

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

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

-- 
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at

"Wolfgang Mahringer" <y...@gmx.at> wrote in message 
news:37FFg.4$z...@news.salzburg-online.at...

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

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

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

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.

Wolfgang Mahringer wrote:
> Hi,
>
> p...@hotmail.com wrote:
>
> > "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.
>
> 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.

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.