Problem mit CRC16 Berechnung (Hin/Rückrechnung)

[Oz z. (ozzy)]

Hi,

ich möchte meine zu sendenden Daten über eine CRC16 absichern. Die 
crc16.h bietet mir für meinen Atmega ja schon mal einen guten 
Anhaltspunkt:

uint16_t U16crc;

void crc_fInit( void )
{
  U16crc = 0xffff;
}

void crc_fUpdate(uint8_t value)
{
  uint8_t i;

  U16crc ^= value;
  for (i = 0; i < 8; ++i)
  {
    if (U16crc & 1)
    {
      U16crc = (U16crc >> 1) ^ 0xA001;
    }
    else
    {
      U16crc = (U16crc >> 1);
    }
  }
}

Allerdings will das ganze bei mir nicht klappen.
Also, angenommen ich habe diese Nachricht:

unsigned char message[9] = {'M','e','s','s','a','g','e',0,0};

Dann lasse ich die CRC16 mit den Polynom 0xA001 rüberlaufen:

    crc_fInit();
    for (i=0; i<9; i++)
    {
      crc_fUpdate(message[i]);
    }

Als Ergebnis erhalte ich hier "54110".
Nun kopiere ich dieses Ergebnis in die letzten beiden "Zeichen"

    message[7] = (U16crc>>8);
    message[8] = (U16crc & 0xFF);

und lasse den Algorithmus erneut über die Nachricht laufen (was ja nun 
die Empfängerseite wäre):

    crc_fInit();
    for (i=0; i<9; i++)
    {
      crc_fUpdate(message[i]);
    }

Allerdings bekomme ich hier nicht die erwartete "0", sondern eine "7042" 
als Ausgabe.

Sehr Ihr vielleicht, wo hier der Fehler stecken könnte?

Vielen Dank im Voraus für Eure Hilfe!!!

[Georg G. (df2au)]

Oz zy schrieb:
> Nun kopiere ich dieses Ergebnis in die letzten beiden "Zeichen"

Das ist nicht ganz richtig. Berechne CRC über die Nutzdaten (7 Zeichen 
in deinem Fall) und hänge dann die CRC dran. Achte auf die richtige 
Reihenfolge.

Es gibt n+1 erprobte und fehlerfreie Implementationen im Netz. Bei 
GCC-AVR ist auch eine Lib dabei. Warum das Rad neu erfinden?

[Oz z. (ozzy)]

Hi,

erst einmal danke für Deine Antwort! Ich hatte es immer so verstanden, 
dass für die CRC zuerst so viele Nullen (in Bits) an die Nachricht, wie 
das Polynom groß ist. Über diese neu entstandene Nachricht wird dann die 
CRC-Summe gebildet. Anschließend wird an den Rahmen (dann allerdings 
ohne die Nullen) die Summe angehängt.

Ich erfinde ja auch das Rad nicht neu. Der Code, den ich oben 
geschrieben habe ist der aus der avr-lib. Ich habe nur die crc global 
gemacht, so dass sie nicht mitübergeben werden muss...

Viele Grüße
Ozzy

[Purzel H. (hacky)]

Man muss eh die implementation des CRC haben, dh den sourcecode. dann 
macht man den eben auf beiden Seiten gleich und gut ist.

[Stefan E. (sternst)]

Oz zy schrieb:
> Ich hatte es immer so verstanden,
> dass für die CRC zuerst so viele Nullen (in Bits) an die Nachricht, wie
> das Polynom groß ist.

Eine CRC wird über einen Bitstrom gebildet. Die Länge dieses Bitstroms 
und die Größe des CRC sind komplett unabhängig voneinander. Du könntest 
auch eine 64-Bit-CRC über 5 Bits erstellen (ohne irgendetwas auffüllen 
zu müssen). Dass die CRC-Funktionen die Bits in "Paketen" (8, 16, 32, 
... Bits) entgegennehmen, dient nur der Bequemlichkeit.

[Oz z. (ozzy)]

Hm,

ich kenne es eben auch aus Büchern so, wie es bei Wikipedia beschrieben 
ist (ich weiß, das ist nicht die Quelle aller Quellen). Und da wird eben 
doch etwas angehängt...

[Stefan E. (sternst)]

Oz zy schrieb:
> ich kenne es eben auch aus Büchern so, wie es bei Wikipedia beschrieben
> ist (ich weiß, das ist nicht die Quelle aller Quellen). Und da wird eben
> doch etwas angehängt.

Wo (Link)?

[Oz z. (ozzy)]

http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Verfahren
bzw. hier als Beispiel:
http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Beispiel

[Stefan E. (sternst)]

Da wird doch nur für die theoretische Betrachtung (bzw. das
händische Dividieren) was angehängt. Bei einer realen 
CRC-Implementierung ist dieses "Anhängsel" der CRC-Startwert, und nichts 
was du deinen Nutzdaten hinzufügen müsstest.

[Oz z. (ozzy)]

Ok, danke, dann bin ich damit schon mal schlauer. Stimmt es aber 
trotzdem, dass, wenn ich die CRC an die Nachricht anhänge und den 
Algorithmus erneut durchlaufen lasse, eine "0" rauskommen sollte?

[Stefan E. (sternst)]

Oz zy schrieb:
> Stimmt es aber
> trotzdem, dass, wenn ich die CRC an die Nachricht anhänge und den
> Algorithmus erneut durchlaufen lasse, eine "0" rauskommen sollte?

Ja.

[Peter II (Gast)]

Oz zy schrieb:
> Ok, danke, dann bin ich damit schon mal schlauer. Stimmt es aber
> trotzdem, dass, wenn ich die CRC an die Nachricht anhänge und den
> Algorithmus erneut durchlaufen lasse, eine "0" rauskommen sollte?

ja, so mache ich es auch. Aber wenn ich mich recht daran erinnere denn 
errechne ich die CRC ohne die beiden 0 bytes. Könnte ich heute abend mal 
nachschauen.

[Oz z. (ozzy)]

Ok, also selbst wenn ich so mache funktioniert es nicht...
Also bei der ersten CRC-Berechnung:

    crc_fInit();
    for (i=0; i<7; i++)
    {
      crc_fUpdate(message[i]);
    }

Als Ergebnis kommt da "15420" raus. Also weit weg von einer 0...

[Stefan E. (sternst)]

Oz zy schrieb:
> Also bei der ersten CRC-Berechnung:
> ...
> Als Ergebnis kommt da "15420" raus. Also weit weg von einer 0...

Wieso sollte da denn jetzt auch 0 raus kommen?

[Peter II (Gast)]

Oz zy schrieb:
> Als Ergebnis kommt da "15420" raus. Also weit weg von einer 0...

ist ja wohl klar, wenn du jetzt aber die  "15420" in der richtige 
Reihenfolge anghägst und dann über die 9 zeihcen die CRC brechnest dann 
sollte eine 0 rauskommen.

[Stefan E. (sternst)]

Peter II schrieb:
> Aber wenn ich mich recht daran erinnere denn
> errechne ich die CRC ohne die beiden 0 bytes.

Diese "beiden 0 bytes" sind in Wirklichkeit der Startwert.

[Oz z. (ozzy)]

Sorry, da habe ich mich unglücklich ausgedrückt. Ich berechne die CRC 
über die Nachricht (ohne Anhang). Ergebnis: "31531". Diese 2 Byte hänge 
ich an die Nachricht dran, und lasse die CRC-Berechnung nun über die 
Nachricht + CRC laufen. Ergebnis: "15420" != "0"...

[Peter II (Gast)]

Oz zy schrieb:
> Ergebnis: "31531". Diese 2 Byte hänge
> ich an die Nachricht dran,

dann tausche mal die reihenfolge der bytes.

[Oz z. (ozzy)]

Shit, shit, shit, genau das war es!!!!!! Ich dachte, ich hätte das schon 
ausprobiert...

Vielen, vielen Dank auf jeden Fall für Hilfe!!!

MfG, Ozzy