Searching \ for 'Async receiver questions (PIC17C4X)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Async receiver questions (PIC17C4X)'.

Truncated match.
PICList Thread
'Async receiver questions (PIC17C4X)'
1995\10\16@125504 by Stephen P (Steve)

flavicon
face
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
spam_OUTspconkliTakeThisOuTspamingr.com

1995\10\16@150723 by Mike Keitz

flavicon
face
>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?

[Description of 17CXX async receiver removed]

>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.
>
The essence of asyncronous data (i.e. why it is asynchronous) is that
synchronization is re-acquired with every start bit.  Therefore, jitter or
clocking errors span only over one character, and it is generally OK to
sample blindly rather than trying to extract a clock from the data.  Logic
that looks for edges in the data and tries to adjust the sampling points, in
addition to being unnecessary, could be fooled by noise and jitter.  Some of
the Motorola MCUs have that, but it appears to me to be just fluff.

The quote about "having no relationship to the falling edge of the start
bit" is not on my (preliminary) data sheet.  In order for it to be
asynchronous reception, the reception process must be synchronized to the
start bit in some way.  Probably what they are trying to say is that the
falling edge of the start bit resets the sample counter to 0, but doesn't
adjust the phase of the x16 clock.

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

If you require 'high data integrity', some sort of error control will be a
must.  Perhaps synchronous data would be better, as then the integrity of
the single event of the falling edge of the start bit (which is essential
for any asynchronous receiver) would be less important.  But overall, data
integrity is going to be long-gone before it reaches *any* receiver, if a
lot of noise gets into the wiring due to poor choice of line transceivers
and cable.  This is the area to concentrate on in the industrial
environment, rather than relying on voodoo at the receiver to make it all
better.

-Mike

1995\10\16@222456 by PETE KLAMMER

flavicon
face
{Quote hidden}

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?

Peter F. Klammer, Racom Systems Inc.                   .....PKlammerKILLspamspam.....ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

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