CCITT CRC 16 Bit Startwert 0xffff

Muss ich berechnen CCITT 16-bit-Prüfsumme Wert für die Daten als parameter übergeben, zusammen mit der Länge. Wenn ich füllen mein array TempStr mit den test-Daten "123456789", verwenden Sie das Polynom 0x8408 mit der Länge ohne null-Terminierung-Charakter, habe ich das Ergebnis bekommen, das string-6E90(Hex). Zusammen mit der null-Terminierung char bekomme ich 907A. Wenn ich die swap-Polynom zu 0x1201 dann bekomme ich die Ergebnisse 29E2(Hex) und EFE8(Hex) mit und ohne Terminierung Charakter.

Meine Fragen sind:
Muss ich zum berechnen des CRC mit oder ohne null-Terminierung-Charakter zu erhalten, den richtigen Wert?
Verwende ich das Polynom 0x1201 oder das reverse Polynom 0x8408 in dem Algorithmus?
Ist die korrekte CRC der Daten 0x29B1? Ich brauche den richtigen Wert zu ermitteln, ob die Funktion korrekt funktioniert..
Ist der Algorithmus zur Berechnung dieses speziellen CRC-Typ korrekt?
wData=(unsigned int)0xff & *pData++??
Wenn jemand zu mir erklären können, was falsch ist und, wie zu beheben mein problem, würde ich viel schätzen.
Danke

Dies ist der code, verwendet und zeigt die calculate_CRC16 Funktion:

CHAR_t TestStr[] = {"123456789"};
unsigned short CrcTest = calculate_CRC16(TestStr,sizeof(TestStr)-1);
QString CrcDisplay = QString("CrcTest : %1").arg(CrcTest);
ui->txtDebug->setText(CrcDisplay);

Dies ist die calculate_CRC16 Funktion:

UINT16_t MainWindow::calculate_CRC16(CHAR_t* pData, UINT16_t wLength)
{

  UCHAR_t i;
  UINT16_t wData;
  UINT16_t wCrc = 0xffff;

  if (wLength == 0)
    return (~wCrc);

  do
  {
    for (i=0, wData=(unsigned int)0xff & *pData++; i < 8; i++, wData >>= 1)
    {
        if ((wCrc & 0x0001) ^ (wData & 0x0001))
            wCrc = (wCrc >> 1) ^ CRC_POLY;
        else  wCrc >>= 1;
    }
  } while (--wLength);

  wCrc = ~wCrc;
  wData = wCrc;
  wCrc = (wCrc << 8) | (wData >> 8 & 0xff);

  return (wCrc);
}

Ich habe nie gesehen, CRC-Prüfungen, die auch die abschließende null-oder line feeds oder sonstwas. Für die anderen Fragen, sorry, nicht genug von einem Experten.
Ob oder nicht-terminierenden null-oder line-feeds enthalten sind, in die CRC-Berechnung ist völlig davon abhängig, ob Sie einen Teil der Daten überprüft werden, die am empfangenden Ende. Sie müssen, um die CRC zu was auch immer Daten, die das andere Ende wird der CRC auf. Beachten Sie auch, dass einige CRC-Berechnung Funktionen müssen dummy-Daten (zum Beispiel eine gewisse Anzahl von Nullen) 'gedrängt' durch die CRC-Funktion, um die endgültige CRC aus einem internen state machine. Dies gilt in der Regel für eine CRC-Funktionen, die entworfen sind, zum berechnen einer CRC über mehrere Anrufe mit progressiven Daten.

InformationsquelleAutor Ruaan Volschenk | 2014-01-21

c++checksum crc crc16

Ergebnis 0x29b1 ist für die "false" CCITT CRC-16 (link zu CRC-Katalog). Das ist offenbar die, die Sie brauchen. Aus dem Katalog:

width=16 poly=0x1021 init=0xffff refin=false refout=false xorout=0x0000 check=0x29b1 name="CRC-16/CCITT-FALSE"

Also es gibt keine bit-Umkehrung (refin, refout false). Die CRC wird initialisiert mit 0xffff und ist nicht nachbearbeitet.

Befestigen Sie Ihr code mit den wenigsten änderungen:

if (wLength == 0)
    return wCrc;

do
{
    for (i=0, wData=((unsigned int)0xff & *pData++) << 8; i < 8; i++, wData <<= 1)
    {

        if ((wCrc & 0x8000) ^ (wData & 0x8000))
            wCrc = (wCrc << 1) ^ 0x1021;
        else  wCrc <<= 1;
    }
} while (--wLength);

return wCrc & 0xffff;

oder zu tun, es einigermaßen:

while (wLength--) {
    wCrc ^= *(unsigned char *)pData++ << 8;
    for (i=0; i < 8; i++)
        wCrc = wCrc & 0x8000 ? (wCrc << 1) ^ 0x1021 : wCrc << 1;
}
return wCrc & 0xffff;

Diese neue und einfache Stück code funktioniert sehr gut. Vielen, vielen Dank!

InformationsquelleAutor Mark Adler

2

Wenn Sie einen Blick auf, es wird berechnen Sie den CRC für die verschiedenen Zeichenketten (oder hex-Sequenzen, die für die überprüfung mit oder ohne NUL)
http://www.lammertbies.nl/comm/info/crc-calculation.html

Nach, dass, sollten Sie NICHT berechnen, einschließlich des abschließenden null um den Wert der 0x29B1 für Ihre Berechnung.

Da sind Sie, beginnend mit dem low-bit, Sie sollten mit den "non-reverse" - Polynoms.

Ich denke, das problem ist, dass Sie eine Verschiebung der falsche Weg, wenn Sie die Verlagerung der "wCrc" in Ihrer Berechnung.

In anderen Worten:
```
wCrc = (wCrc >> 1) ^ CRC_POLY;
```
werden sollte:
```
wCrc = (wCrc << 1) ^ CRC_POLY;
```
ebenso:
```
wCrc >>= 1;
```
werden sollte:
```
wCrc <<= 1;
```
Allerdings bin ich mir nicht 100% sicher.

InformationsquelleAutor Mats Petersson
0

Gibt es eine Reihe von verschiedenen Varianten von CRC-algorithmen.
- Bit-durch-bit-Berechnung versus lookup-Tabelle
- Reflektiert bytes versus nicht-reflektierten bytes (MSbit oder LSbit).
- Anhängen von augmented-bits an das Ende der Meldung, oder nicht.
Dieser Letzte Punkt ist eine Frage der Verwirrung. Gehen wir zurück zu CRC-Theorie, CRC gesehen werden kann, wie lange die division in GF(2), wobei das Ergebnis den Rest der division mit Rest. Um eine korrekte Berechnung nach base-Theorie, n null-bits angefügt werden muss, um das Ende der Nachricht, um die richtige Antwort. Gibt es CRC-algorithmen, die die Berechnung auf diese Weise.

Jedoch häufiger CRC-algorithmen, die fertig sind einen anderen Weg, so dass die Nachricht muss nicht-null-bits angehängt, um das Ende der Nachricht. Diese Berechnung wird oft als die "direct-Algorithmus". Es ist bequemer zu bedienen und funktional, außer, dass jeder "Anfangswert" des Algorithmus modifiziert werden, um für dieses Konto Variante-Algorithmus.

Im Falle von CRC-16/CCITT, dies führt zu Verwirrung, da auf den richtigen Anfangswert: sollte es 0xFFFF oder 0x1D0F? Wohl 0xFFFF ist der richtige Startwert für den Algorithmus fügt augmented-bits an die Nachricht an. Wenn Sie die "direct-Algorithmus", der erste Wert muss eingestellt werden, um 0x1D0F das gleiche Ergebnis zu erhalten.

So müssen Sie sich bewusst sein, dieser Unterschied, und je nachdem, was benötigt wird, um inter-die Arbeit mit dem Programm/system-Sie sind die Schnittstellenfunktion mit.

Weiter Lesen:
- CRC-CCITT -- 16-bit (andere Quelle)
- Kapitel 10, "Leicht" Verstümmelt Tisch-Driven Umsetzung", Ein Painless Guide to CRC Error Detection Algorithmen von Ross Williams
- CRC-16/AUG-CCITT versus CRC-16/CCITT-FALSE in der Katalog der parametrierten CRC-algorithmen
- Online CRC-Rechner die es erlaubt die Berechnung mit "Indirekter" und "direkter" algorithmen und Konvertierung der Ausgangswerte zwischen diesen beiden algorithmen.
InformationsquelleAutor Craig McQueen

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.