(Stupid/Newbie) Question on UART

Hello,

	I am wondering if someone could clear this doubt for me, in case of
UART, the clock speed is 1.8432 MHZ, however it is able to transmit
maximum of 115,200 bps, however even if we are able to transmit at 1
bit per cycle we should be able to transmit at 1,843,200 bps. What is
the rationale for making something go slowly, when it can go much
faster.


PS, I really could not find any suitable group for this question,
follow-ups to a more suitable group are welcome.

TIA
-- 
Imanpreet Singh Arora

>	I am wondering if someone could clear this doubt for me, in case of
>UART, the clock speed is 1.8432 MHZ, however it is able to transmit
>maximum of 115,200 bps, however even if we are able to transmit at 1
>bit per cycle we should be able to transmit at 1,843,200 bps. What is
>the rationale for making something go slowly, when it can go much
>faster.

The traditional implementation uses a 16x clock on the receiver.

It looks for the transition on the leading edge of the start bit,
then starts counting. After 1.5 baud times, it samples the first bit
in the byte.  That's the middle of the bit cell.

16*115200 is 1843200

You can use slower clocks, say 8x, but they you will (sometimes) be
farther from the center of the bit cell and errors will be more likely.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:tdednf4NTuXAL6_fRVn-vg@megapath.net...
> > I am wondering if someone could clear this doubt for me, in case of
> >UART, the clock speed is 1.8432 MHZ, however it is able to transmit
> >maximum of 115,200 bps, however even if we are able to transmit at 1
> >bit per cycle we should be able to transmit at 1,843,200 bps. What is
> >the rationale for making something go slowly, when it can go much
> >faster.
>
> The traditional implementation uses a 16x clock on the receiver.
>
> It looks for the transition on the leading edge of the start bit,
> then starts counting. After 1.5 baud times, it samples the first bit
> in the byte.  That's the middle of the bit cell.

The oversampling not only makes it possible to determine the position of the
start bit, but also it combats the noise and errors. The 16 consecutive
sampled values (each being 0 or 1) are used to decide on the actual bit
value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0. A
better (in terms of error immunity) UART is one that works with a current
loop instead of the regular that works with voltage.

> 16*115200 is 1843200
>
> You can use slower clocks, say 8x, but they you will (sometimes) be
> farther from the center of the bit cell and errors will be more likely.

The start bits help to resynchronize. If the data flow isn't continuous but
often have all ones, the receiver and xmitter clocks may not match each
other well, provided all bits in a byte are decoded correctly. Good hardware
implementations may adjust themselves to the clock offset.

Alex

> The start bits help to resynchronize. If the data flow isn't continuous but

Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the
pauses between bytes can be of arbitrary time. Only the timings between bits in
a byte are established.

Serial line has no notion of the "packet".

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:d0ur3u$1vn9$1@gavrilo.mtu.ru...
> > The start bits help to resynchronize. If the data flow isn't continuous
but
>
> Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the
> pauses between bytes can be of arbitrary time. Only the timings between
bits in
> a byte are established.
>
> Serial line has no notion of the "packet".


Packetization is an artificial thing. Normally, the physical data channels
are continuous and bear no idea of any data packetization. Packets are just
a way to transfer data in portions, which is most useful in the channels,
where the data can be lost or corrupted. Chunks of data are numbered and
redundancy is appended to make sure anything lost or corrupted can be
requested for retransmission. Another way to combat data corruption is to
add the redundancy into the data itself, by some forward error correction
(FEC) mechanism. The receiving party can recover some errorneus bits in the
data from the data with added redundancy. Although FECs can help a lot,
they're not always practical because they require bigger bandwith and of
course not every error can be corrected with them (the Hamming distance of
the FEC determines the correcting performance).

Alex

On Sat, 12 Mar 2005 16:36:31 +0300, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> The start bits help to resynchronize. If the data flow isn't continuous but
>
>Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the
>pauses between bytes can be of arbitrary time. Only the timings between bits in
>a byte are established.
>
>Serial line has no notion of the "packet".

Actually with 10mb/s Ethernet and USB (all speeds) there is no carrier
on the wire when actual data is not begin transmitted. Clock recovery
starts at an arbitraty point with every packet.

> > Serial line has no notion of the "packet".
>
>
> Packetization is an artificial thing. Normally, the physical data channels
> are continuous and bear no idea of any data packetization.

Oh no.

The Ethernet packet cannot have pauses between bytes, it is transmitted as the
single entity time-wise. Same are USB packets, though they are smaller.

Serial UART has no notion of such mode at all. This is why it is called "async"
in Cisco IOS.

There are also some serial attachment cables which have the notion of the
packet (transmitted as single entity time-wise, I also expect this interface to
have packet headers). They were used in X.25 equipment, and are incompatible
with UART cabling. Cisco IOS called this interface "serial".

The PPP protocol requires the packet-based underlying physical media. So, to
run PPP over the UART line (which means - usual modem) - escape bytes are used
to denote the packet boundaries. It is described in the PPP RFC as appendix. In
Windows, this logic is in AsyncMac.sys which "packetizes" the serial UART line.

>Packets are just
> a way to transfer data in portions, which is most useful in the channels,
> where the data can be lost or corrupted.

Another very, very major purpose of packetization is time-sharing the single
physical media line for several traffic flows.

> requested for retransmission. Another way to combat data corruption is to
> add the redundancy into the data itself, by some forward error correction
> (FEC) mechanism.

Most network media do not use ECC, they use the stupid checksums. The recovery
is done via retransmission. ECC is used in storage, not networking.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

> Actually with 10mb/s Ethernet and USB (all speeds) there is no carrier
> on the wire when actual data is not begin transmitted.

Same as with serial UART.

>Clock recovery
> starts at an arbitraty point with every packet.

USB packets have a preamble to synchronize the PLLs. IIRC Ethernet too.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

imanpreet@gmail.com wrote:
> Hello,
> 
> 	I am wondering if someone could clear this doubt for me, in case of
> UART, the clock speed is 1.8432 MHZ, however it is able to transmit
> maximum of 115,200 bps, however even if we are able to transmit at 1
> bit per cycle we should be able to transmit at 1,843,200 bps. What is
> the rationale for making something go slowly, when it can go much
> faster.

You are correct, that it is technically possible to SEND at 1.842MHz, 
and some modern UARTS have this option ( see Oxford semi ).
The problems are on RECEIVE, where historically a 16x sample rate
was chosen for the RX Clock. The 16x is not mandatory, but a trade off 
between speed and clock drift/edge jitter tolerance.
Some devices have variable sample rates : /8 is often seen, and even /5,
and some uarts can output/input a clock, but by that stage they have 
morphed away from the ASYNC approach.
Because the issue is one of phase of sample, not frequency per-se, with
devices like FPGAs that have Digital Delay lines, you could design a
UART with a RX clock == BAUD rate, and choose the delay line tap, on 
each start bit.
-jg

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:d0vc6j$2a19$1@gavrilo.mtu.ru...
> > requested for retransmission. Another way to combat data corruption is
to
> > add the redundancy into the data itself, by some forward error
correction
> > (FEC) mechanism.
>
> Most network media do not use ECC, they use the stupid checksums. The
recovery
> is done via retransmission. ECC is used in storage, not networking.


If the retransmissions are very costly (e.g. half-duplex physical channels)
but the BER (Bit Error Rate) is good enough, error correction is quite
efficient.

Alex