Post by thread:17C5x async serial I/O

I've coded up some interrupt-driven serial-port code for the 17C5x, with flow control of output, and filled hundreds of screens of MS-Kermit under Windows 3.11 at 115200bps (with 16550 chips and TurboCom/2 drivers) with no apparent misses. Although this was mostly output from the PIC, with keystroke-rate input, I never noticed anything dropped. Not a good test, just an observation. But the PIC data book narrative *is* scary: if you look at figure 13-4, there is indeed no connection from ``START Detect'' to ``Majority Detect''; in fact, it seems to be the other way around: if the Majority-Detect happens to find 2 out of three bits down, that will be called a start bit. Figure 13-7 is reassuringly misleading: it shows samples 7-8-9 being taken ideally in the middle of the start bit. Whereas in fact, if the narrative is to be believed, 7-8-9 could just as well have happened where 1-2-3 are shown, or where 15-16-1 are, etc. In such cases, it seems that a startbit could be missed, or sampling could fall pathologically on bit boundaries, rather than bit centers! In this case, just a little DC offset or 1-vs-0 duty cycle asymmetry would produce gobs of errors. Hey, Microchip, what's all this ``no relationship'' stuff, anyhow? {Quote hidden}> Date: Mon, 16 Oct 1995 11:54:00 -0500 (CDT) > From: "Conklin, Stephen P (Steve)" <spam_OUTspconkliTakeThisOuTPO4.PCMAIL.INGR.COM> > Subject: Async receiver questions (PIC17C4X) > > I haven't used the PIC before, and am considering it for > an application, but have run across something that troubles > me, and may make it unsuitable for my application. Does > anyone have any comments about the following? > > According to Section 12.2.3 of tthe PIC17C4X Data Sheet, > the sampling of received async data by the SCI is done > as follows: > > [begin quote] > > "The data on the RA4/RX/DT pin is sampled three times > by a majority detect circuit to determine if a high or a low > level is present at the RA4/RX/DT pin. The sampling is > done on the seventh, eighth, and ninth falling edges of > a x16 clock. These sample points have no relationship > to the first falling edge of the start bit. > > The x16 clock is a free running clock, and the three > sample points occur at a frequency of every 16 falling > edges". > > [end quote] > > If the wording weren't so specific, I would be inclined > to disbelieve it. This seems like a terrible way to > design a receiver. > > If this is true, then the receiver is essentially sampling > once per bit period, with no synchronization between > the samples and the data. This would seem to lead to > certain errors if there were any jitter in the data or > difference between the baud rates on the transmitter and > receiver. > > My application requires the receipt of high-speed data > (above 250Kbps) in an industrial environment. I require > high data integrity. The data rates make it impossible > to implement a receiver in software. > > Has anyone tried to use this receiver? What were your > experiences? > > Thanks, > > Steve Conklin > .....spconkliKILLspam@spam@ingr.com Peter F. Klammer, Racom Systems Inc. PKlammerKILLspamACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708