home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
archives
/
protocol.tar.gz
/
protocol.tar
/
crc.txt
< prev
next >
Wrap
Internet Message Format
|
2002-10-19
|
2KB
From fdc@columbia.edu Sat Oct 19 06:27:27 2002
Flags: 000000000001
Return-Path: <fdc@columbia.edu>
Received: from watsol.cc.columbia.edu (localhost [127.0.0.1])
by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9JFRQq5008010
for <fdc@columbia.edu>; Sat, 19 Oct 2002 11:27:26 -0400 (EDT)
Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g9JFRQoM008009
for fdc; Sat, 19 Oct 2002 11:27:26 -0400 (EDT)
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!wn11feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail
Message-ID: <3DB1547F.410E0CB@yahoo.com>
From: CBFalconer <cbfalconer@yahoo.com>
Reply-To: cbfalconer@worldnet.att.net
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.arch.embedded
Subject: Re: HDLC CRC Calculation
References: <3daf2442.670703@news.saix.net>
Content-Transfer-Encoding: 7bit
Lines: 22
Date: Sat, 19 Oct 2002 14:09:33 GMT
NNTP-Posting-Host: 12.90.172.183
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 1035036573 12.90.172.183 (Sat, 19 Oct 2002 14:09:33 GMT)
NNTP-Posting-Date: Sat, 19 Oct 2002 14:09:33 GMT
Xref: newsmaster.cc.columbia.edu comp.arch.embedded:139330
Content-Type: text/plain; charset=us-ascii
To: undisclosed-recipients:;
Anton Erasmus wrote:
>
> On all the Serial Controllers I have used that supports HDLC,
> there are 2 options for the standard HDLC CRC Calculation, namely:
> Preset CRC with all 0s or all 1s. From a technical point of view
> there does not seem to be any advantage in using the one over the
> other. Is there any sort of preference in the various protocols
> based on HDLC for either the one or the other option ?
If the CRC is preset to 1's, input of a series of 0's will change
it. That means you will always detect a too short, or too long,
stream of 0's. If you preset to 0, things will not change with
each zero byte input. If the input stream ends with its own CRC,
in the correct byte order, the end result will be 0, which is a
handy final check mechanism.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!