Searching \ for 'RS232 Stop Bit(s)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/serials.htm?key=rs232
Search entire site for: 'RS232 Stop Bit(s)'.

Truncated match.
PICList Thread
'RS232 Stop Bit(s)'
1997\05\28@203748 by Ross McKenzie

flavicon
face
Hi Everyone,

My limited reading to date on the Basic versions of PICs appears to indicate
that their serial comms routines are _only_ suited to the use of a single
stop bit. Is this correct?

I have an potential application that must cope with 2 stop bits and was
considering doing the coding in one of the Basic codes. Is this possible?

Regards,

Ross McKenzie
Melbourne Australia

1997\05\28@204825 by William Chops Westfield

face picon face
   I have an potential application that must cope with 2 stop bits and was
   considering doing the coding in one of the Basic codes. Is this possible?

Receive code written for one stop bit will work fine if it gets two stop
bits (the extra stop bit looks like a bit worth of inter-character gap.)

Transmit code that only generates one stop bit MIGHT have trouble being read
by two-stop-bit hosts if data is sent with no between-character gaps, or it
might not...

BillW

1997\05\29@001938 by Harold M Hallikainen

picon face
       As pointed out by someone else, you can receive stuff transmitted
with two stop bits on a serial port set to do one.  The PIC can send 9
data bits.  The ninth bit can be used for parity or set for marking
parity, which is equivalent to an extra stop bit.
       Another trick I used where I had to send a break between a couple
characters (which was done by putting a resistor in series with the
serial tx line out of the pic, then tying it to another port line that
was either tri-stated (letting data go through) or programmed low,
forcing a break).  The trick was to get the break to not land on top of
characters.   Double buffering of the serial port made it difficult to
figure out when one character was finished transmitting and I could
assert the break.  This was using the serial port transmit interrupt,
which generates an interrupt when the transmit buffer (not shift
register) is empty.  What I ended up doing was ignoring the transmit
interrupt and instead used a timer interrupt.  Each time the timer
interrupt is called, it dumps a character into the serial port.  A VERY
short time later, it starts clocking out.  Since the stuff was not
buffered by the serial port (it started transmitting almost immediately),
I was able to assume when the next timer interrupt was called that the
previous byte had been sent and it was ok to set the break.  So... back
to your problem, you can do something similar (use the timer interrupt
instead of the transmit interrupt) and set the timer for the time
required to transmit the byte plus the start bit plus the two stop bits.
The transmitter will sit idle waiting for the next interrupt to load it.
The idle transmitter is in the mark condition, just like a stop bit!


Harold

1997\05\29@001947 by John Payson

flavicon
face
> My limited reading to date on the Basic versions of PICs appears to indicate
> that their serial comms routines are _only_ suited to the use of a single
> stop bit. Is this correct?
>
> I have an potential application that must cope with 2 stop bits and was
> considering doing the coding in one of the Basic codes. Is this possible?

A "stop bit" is nothing more than a little bit of guaranteed idle time
between characters.  It is included in the data because otherwise accurate
interpretation of long strings of zero bytes would be impossible.  For
example, the sequence of bytes [$00 $00 $00] would be sent as

"...11111110000000000000000000000000001111..." [27 zeroes]

whereas the sequence of bytes [$00 $00 $80] would be sent as

"...1111111000000000000000000000000001111..." [26 zeroes]

Accurate discrimination between [27 zeroes] and [26 zeroes] is not
practical, and discrimination between, say, [270 zeroes] and [269 zeroes]
would be all but impossible.

Instead, with stop bits added, the sequence [$00 $00 $00] is sent as

"....1111110000000001000000000100000000011111...."

Much easier to intperpret.

Because a stop bit is nothing more than guaranteed line-idle time, extra
stop bits may be generated by simply waiting between characters.  If at
1200 baud you send a character, wait 1ms, send a character, wait 1ms, etc.
then you will be effectively adding slightly over a stop bit for each
character [assuming that each wait starts after the end of the first
"guaranteed" stop bit].  As for receipt of data with stop bits, this
usually poses no problem since the receiver has to deal with the
possibility of an idle line anyway.

Normally, the only time that stop bits pose a problem is when a
receiver--by design--requires a certain amount of time between characters
in which to "think" or "do things".  This is an especially common problem
when using bit-bang 'uarts' to receive data; the receiver has to do all of
the processing associated with a byte between the middle of the last data
bit and the beginning of the next start bit (and it's better if the
receiver can wait until the middle of the stop bit before doing its
processing).  Consequently, the receiver will only have 1/2 to 1 1/2 bit
times in which to decode/process each character.  Adding another stop bit
will increase the available time by 66-200%.  This can help things
markedly.

Another slightly different application where stop bits may be an issue is
in conversion from 38400-M-2 [mark parity, two stop bits] to 31250-N-1
[MIDI format].  A PIC could handle such a translation fairly easily real
time, *BUT* the stop bits on the MIDI side would be about 1/4 bit-time too
short.  Some synthesizer keyboards may expect to have a full stop bit time
and may balk at the shortened stop bit.  On the other hand, there is no
useful data speed on a normal PC between 38400-M-2 [3200 bytes/sec] and
23040-N-1 [which would be too slow to receive MIDI data].

1997\05\29@085254 by Andy Kunz

flavicon
face
At 10:38 AM 5/29/97 +1000, you wrote:
>Hi Everyone,
>
>My limited reading to date on the Basic versions of PICs appears to indicate
>that their serial comms routines are _only_ suited to the use of a single
>stop bit. Is this correct?
>
>I have an potential application that must cope with 2 stop bits and was
>considering doing the coding in one of the Basic codes. Is this possible?

Receiving 2 stop bits is very easy - regular 1-stop-bit code works fine.

Transmitting 2 stop bits in software is very easy - just delay 1 bit time
before transmitting the next byte.

FWIW, the second stop bit is typically used to enable a slow device to
process the received character.  I use it on some of my rs-232-in-sw stuff
to enable me to store, validate, and otherwise process the last character
received.  Basically, think of it as a 10% lengthening of the time between
characters.  Kind of like the old "pace" characters you needed on early XT's.

Andy

======================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 USA
             Electronics for Industry & R/C Hobbyists
        "Go fast, turn right, and keep the wet side down!"
======================================================================

1997\05\29@182334 by Lee Jones

flavicon
face
>> I have an potential application that must cope with 2 stop bits

> A "stop bit" is nothing more than a little bit of guaranteed idle time
> between characters.  It is included in the data because otherwise accurate
> interpretation of long strings of zero bytes would be impossible.  For
> example, the sequence of bytes [$00 $00 $00] would be sent as
>
> "...11111110000000000000000000000000001111..." [27 zeroes]
>
> whereas the sequence of bytes [$00 $00 $80] would be sent as
>
> "...1111111000000000000000000000000001111..." [26 zeroes]
>
> Accurate discrimination between [27 zeroes] and [26 zeroes] is not
> practical, and discrimination between, say, [270 zeroes] and [269 zeroes]
> would be all but impossible.

All my comments assume we're talking about serial lines using
an EIA-232 (formerly RS-232), -422, -423, -485, current loop
or similar interface.


Assuming that your diagrams are showing the voltage levels on
an _asynchronous_ serial line, then your statements are wrong.

For async serial, you have completely ignored the start bits.

Your sample of three all-zeros octets [$00 $00 $00] sent as a
consecutive block (no inter-character delay) on an async serial
line would appear as follows:

  ...MT00000000PT0000000PT00000000PM...     <-- 1 stop bit

  ...MT00000000PPT0000000PPT00000000PPM...  <-- 2 stop bits

Where M is the constant voltage inter-character marking state,
T is the start bit, and P is the stop bit(s).

The stop bit ensures that the line is in a marking state prior
to the next start bit and guarantees that the receiver circuit
can detect the leading edge of the start bit.

The series of ...1111... you show at either end surrounding
the data bits imply that an async line has fixed time slots.
This is wrong.  There are no voltage transitions between
characters.  Timing is all predicated on the leading edge of
the start bit.


If you are discussing synchronous serial lines, then the modem
recovers clock timing information from the encoded data stream
or uses the clock signal from the interface.  If the line did
not have a modem, them the timing pulses must be provided by
some clock generator.

In any case, it would certainly be able to discriminate between
270 and 269 bits -- be they all zeros, all ones, or any combination.


> Normally, the only time that stop bits pose a problem is when a
> receiver--by design--requires a certain amount of time between
> characters in which to "think" or "do things".

Or by mechanical necessity.

The only device requiring 2 stop bits that I've worked with was
the old (really old) Teletypes.  They ran at 110 baud and each
character was 11 bits; 1 start bit, 7 data bits, 1 parity bit,
and 2 stop bits.  This gave 10 characters/second.  The marketing
literature quoted it as 100 words/minute.  :-)

It was a totally electro-mechanical device.  There was a motor
inside that rotated continuously and a shaft that rotated once
per character (if I recall details correctly, it's been decades).

When the start bit arrived, it energized a clutch which tied the
shaft to the spinning motor.  It needed 2 stop bits to let the
shaft complete a rotation and declutch in preparation for the
next character.
                                               Lee Jones

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...