| Title: | AMIGA NOTES |
| Notice: | Join us in the *NEW* conference - HYDRA::AMIGA_V2 |
| Moderator: | HYDRA::MOORE |
| Created: | Sat Apr 26 1986 |
| Last Modified: | Wed Feb 05 1992 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5378 |
| Total number of notes: | 38326 |
I was just going over the documentation I got with the 500 and found
something a little strange in the serial port set up documentation --
o Stop Bits. Stop bits are bits added to the end of a character that mark
where it ends. You can select either 1 or 2. This is the number of bits
added to each character sent through the serial connector AND THE
NUMBER EXPECTED AT THE END OF EACH CHARACTER THAT IS READ.
The first part is fine but the last part is in direct violation of
the standards that govern asynchronous serial input if they do anything
when their expectations are not met. Has anybody know what actually happens
when the serial port receives only one stop bit when it is 'expecting' two?
(My understanding of the standard was that the receiver was to sample
at the mid-point of the stop bit and then immediatly start looking for a
start of frame transition. If the stop bit value was wrong, you got a
framing error or break condition. The fact that the search for the start
transition started immediatly meant that the transmitter could be up to
5% faster than the receiver in a standard 8 bit frame and still be able
to communicate. With two stop bits sent, the speed mismatch could be up
to 10% with some probability of communicating. If the search does not
start until the full stop bit has been received then the transmitter must
be slower than the receiver for long streams of frames to be received
correctly.)
(Commodore has done this kind of thing before. The software serial
ART routines on the C128 had the same problem.)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4101.1 | VMSNET::WOODBURY | Wed Sep 12 1990 12:56 | 5 | ||
Checking the hardware documentation I found that the Amiga serial port can be set up to receive either 9 or 10 bits including the stop bit (8 or 9 bits excluding the stop bit). That means they could be doing it right or wrong depending on what the driver does. Does anybody have any information on the inner workings of the serial port driver? | |||||
| 4101.2 | FILTON::FENTON_R | Potassium Ethoxide Rules C2H5OOK | Wed Oct 31 1990 04:40 | 8 | |
Now the trouble with this sort of thing is that it attracts people like
me who don't really know what they're talking about. For example, I
reckon that what would happen if a receiving machine got a series of
characters having two stop bits when it was expecting only one would be
that it would interpret the second stop bit as the first bit of the next
character, and thus get everything totally wrong. But, as I said, I
don't really know.
| |||||
| 4101.3 | Sending two and receiving one stop bit is not a problem... | VMSNET::WOODBURY | Wed Oct 31 1990 17:52 | 13 | |
The stop bit is the same line state as an 'idle' line. As a result
a machine receiving two stop bits but expecting only one will see a one
bit-time pause between characters. This works out just fine. The problem
would arise if the receiver DEMANDS two stop bits and does not get them.
In that case it would get the start bit of the next character and report
a framing error. The best chance of success is for the receiver to only
require a little more than half a stop bit. That allows the sender to be
a percent or two faster than the receiver and still be able to communicate
successfully. This is what the UART chips (and the transceiver boards from
the PDP 11 using low level ICs) that I had logic diagrams on did. Since
the AMIGA puts some of this function in software rather than hardware, they
could have done this differently from the 'best' way. If anybody's been
into their code, I'd like to know how they did it.
| |||||