23 Jan
2014
23 Jan
'14
7:46 p.m.
On Jan 23, 2014, at 22:23, Chuck Guzis <cclist at sydex.com> wrote:
When I've done UARTs in FPGAS, I typically only do the
sampling in the middle of the bit period. I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
- Dave
On 01/22/2014 07:58 PM, Eric Smith wrote:
The described problem occurs when using async mode, not sync, but when
using a modem that does synchronous modulation, which is all modems that
use modulations fancier than FSK, i.e. voice-band POTS modems at 2400 bps
and up, and full-duplex 1200 bps, and when NOT using MNP or V.42 error
control implemented in the modem. This means that it was a common
occurrence when using the uPD7201/8274 with early 212, V.22, and V.22bis
modems. It mostly was not seen with V.32 and later modems because those
almost always use V.22 error control.
I went back to the 8274 datasheet and it seems that the designers considered this to be a
feature. In theory, one could simply start the "hunt" for the next start bit
as soon as the last data bit frame had passed--I have no doubt that many chips actually
work exactly this way--that the "stop bit" is a simply an indeterminate marking
period until a space signals the start of the "start bit".
But Intel seems to say in its datasheet that a space during the period of a stop bit is a
framing error--and goes on to say that a half-bit period is added in case of a framing
error. Doubtless Intel considered this a feature.
What I don't know is if the period of the mandatory space bit on receive is also
governed by the "number of stop bits" setting in the mode setup word--or if, as
in many UART chips, this controls only the length of the stop bit on transmit.