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