Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!maytag!watmath!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: ASCII code for BREAK ???
Message-ID: <1991Feb19.032422.26230@watdragon.waterloo.edu>
Date: 19 Feb 91 03:24:22 GMT
References: <drues.666917751@pv320a.vincent.iastate.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
Lines: 65

drues@iastate.edu wrote:
>Can anyone tell me what ASCII code for "BREAK" is???
>I can't find it in ASCII table I have.

Break is not part of ASCII; it's more part of RS232.  Well, actually,
it makes sense in most asynchronous serial protocols, but there aren't
very many that aren't descendants (some legitimate; most bastard) of
RS232.

The details:

When sending data over an asynchronous line (like RS232), the bits (8,
usually) of a character are surrounded by start and stop bits to synchronise
the receiver.  When the line is idle, it transmits a continuous stream of
1's.  When a character is to be sent, it's preceded by a 0 bit, which
signals the receiver that something is coming.  The receiver has been
sampling the line at typically 16 times the bit frequency (38400 times
a second for 2400 baud) looking for a 0 signal.  When it gets it, it
waits half a bit time and checks again, to make sure the 0 bit is really
there.  Then it waits one bit time, reads the bit, waits one bit time,
reads the next bit, etc.  At the end of the last bit, it waits one more
bit time and checks the stop bit (which must be a 1 signal) and goes back
to checking 16 times per bit for a 1->0 transition.  This way, the
received bits are the signal measured on the line in the middle of each
of the transmitted bits.

If the receiver's clock is not at quite the same speed as the
transmitter's, as is inevitably the case, then the times at which the
receiver measures the bits will drift away from the centre.  As long as
you don't get more than 1/2 a bit drift in a single character, the
receiver will still be measuring the right bits and will get the right
values.  It resynchronises to the leading edge of the start bit every
character, so error does not build up forever.

If, at the end of one character, the receiver does not see a 1 level, it
can't accurately find the change to 0 level that indicates the next
character and so it signals a "framing" error.

Note the need for a full stop bit.  If the receiver was running fast,
it might have sampled early in the last data bit and needs to wait
that entire data bit before the line is clear (1) again.  If the receiver
was running slow, it might have sampled almost the end of the last data
bit, and waiting the minimum full bit time will place it at the end of the
stop bit.  If the stop bit were less than a bit, it would be missed.

If your clocks are more accurate than this, you can economise a little,
but it's not really worth it.  The best use of more accurate clocks
is to send more bits between start and stop, but as a practical matter,
it's hard to find chips which will do this.

Anyway, due to the presence of stop bits, if there are 8 data bits, there
are at most 9 bit times (start + 8 data bits of 0) of 0 signal allowed
in a row.  Rules are made to be broken, so you can break this rule
to sens a special signal (a break) to the receiver.  It is not a normal
character, although it looks like a 0 byte with a framing error.
Breaks are typically at least 2 characters long, and often much longer
than that, and are frequently used to reset a receiver somehow or
return it to a sensible state.

If you look at any serial device deriver or serial chip, you'll see
some bit or command to send a break, but this bit does not correspond
to normal data... it's abnormal, just as there is no touch tone
frequency corresponding to hanging up a telephone.
-- 
	-Colin