Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » Warum gibt es CRC16 Routinen mit unterschiedlichen Initialisierungswerten? » Themenansicht

Autor Thread - Seiten: -1-
000
10.03.2014, 20:58 Uhr
rm2
Default Group and Edit
Avatar von rm2

Hallo an alle,

warum gibt es CRC16 Routinen mit unterschiedlichen Initialisierungswerten?

Z9001 (nach Volker) mit 0FFFFH am Anfang der CRC-Berechnung
T316 (Danke an sas) mit 00000H am Anfang der CRC-Berechnung

CRC16 mit 00000H (T316)
----_0FFH_000H_055H_0AAH
2708 FB80 0000 A69F 5D1F
2716 CFC0 0000 4540 8A80
2732 0E1F 0000 05F5 0BEA
2764 FC00 ???? A41F


CRC16 mit 0FFFFH (Z9001)
----_0FFH_000H_055H_0AAH
2708 7CD6 8756 21C9 DA49
2716 CB45 0485 41C5 8E05
2732 2307 3C18 39ED 37F2
2764 8430

stimmen diese CRC-Summen? (ermittelt mit audatec CRC-Programm 2 und 3)


mfg ralph
--
.
http://www.ycdt.net/mc80.3x . http://www.ycdtot.com/p8000
http://www.k1520.com/robotron http://www.audatec.net/audatec
http://www.ycdt.de/kkw-stendal
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
11.03.2014, 08:24 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

CRC ist ein Verfahren.

"Amtliche" CRC-Versionen wie CRC-CCITT schreiben Startwert und Polynom genau vor, aber man kann auch eigene Werte verwenden. Dadruch verändern sich auch die Ergebnisse.

Letztlich haben die Programmierer "ihre" Version programmiert, vielleicht ohne genaue Vorgaben oder ohne Referenzwerte? Die genauen Startwerte und Polynome sind im Prnizip auch egal, solange man auf demselbem System bzw. mit denselben Routinen arbeitet. Und soviel Datenautausch zwischen den Systemen bzw. Prüfsummenvergleich über Systemgrenzen hinweg wird es vermutlich nicht gegeben haben, dass das zu einem größeren Problem würde.

http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung, Abschnitt "Andere Startwerte"
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
11.03.2014, 09:33 Uhr
Rüdiger
Administrator
Avatar von Rüdiger

Hinweis: in der DDR wurde häufig anstelle der CRC das SDLC-Prüfpolynom verwendet. Wird in der Wikipedia als CRC-CCITT bezeichnet.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
11.03.2014, 10:15 Uhr
sas



Hallo Ralph,

die CRC, die in der T-316 gespeichert - gebildet werden, stimmen das habe ich geprüft.

In Wiki steht:
Andere Startwerte

Die Implementierung führt eine Polynomdivision aus, wenn als Startwert 0000… verwendet wird. Oft findet man andere Startwerte, etwa 1111…. Dies entspricht einer Polynomdivision, wenn die ersten n Bits des Datenstroms invertiert werden.

Ein Startwert ungleich 0000… ist vorzuziehen, da fehlende Bits innerhalb führender Nullen im Datenstrom sonst nicht erkannt werden (ebenso wie bei einer gewöhnlichen Division zählen bei einer Polynomdivision führende Nullen nicht).

Sowie was ich auch vermutete, weil die CRC auch auf die zu sendende Information gebildet wird, das Nullproblem.
Zitat:
Nullproblem und Nachbearbeitung

Eine weitere Problematik stellt das Nullproblem dar, welches in zweierlei Form auftritt:

Produziert ein Datenstrom zufällig einen CRC gleich null, so ist der CRC auch dann null, wenn dem Datenstrom zusätzliche Nullen angehängt werden, oder – falls der Datenstrom mit einer oder mehreren Nullen endet – einige dieser letzten Nullen entfernt werden.
Ist dem Ende des Datenstroms der CRC angehängt (so wie es ein Sender eben verschickt) und bei der Übertragung werden (nach dem gesendeten CRC) noch zusätzliche Nullen angefügt, so können diese zusätzlichen Nullen am Ende nicht erkannt werden.

Das Nullproblem in beiden Ausführungen ist unabhängig davon, ob Startwerte gleich null oder ungleich null verwendet werden.

Das Nullproblem in beiden Ausführungen wird vermieden, indem die Bits des CRC-Ergebnisses invertiert werden. Erfolgt im Empfänger die CRC-Prüfung derart, dass der Empfänger einen CRC aus dem empfangenen Datenpaket berechnet, wobei das Datenpaket aus Datenstrom und angehängtem CRC besteht, so ist im Falle eines unveränderten (nichtinvertierten) CRC des Senders der berechnete CRC im Empfänger stets null. Im Falle eines invertierten CRC des Senders ist der berechnete CRC im Empfänger immer der gleiche Wert, dieser wird auch als Magic Number bezeichnet.

Das Nullproblem der zweiten Ausführung kann auch vermieden werden, indem die Reihenfolge der CRC-Bits umgekehrt wird. Unerkannt bleibt jedoch der Fall, wo der CRC gleich null ist, was das Nullproblem der ersten Art darstellt.

Das bisher beschriebene Nullproblem bezieht sich also auf die Problematik, am Ende des Datenstroms zusätzlich hinzugefügte oder verlorengegangene Nullen zu erkennen. Dies ist jedoch nur dann nötig, wenn aufgrund vorherrschender Randbedingungen nicht sichergestellt werden kann, dass die Größe der Daten unverändert bleibt.

Von einem Nullproblem spricht man jedoch bisweilen auch dann, wenn es problematisch ist, wenn ein Datenstrom aus lauter Nullen auch einen CRC gleich Null erzeugt. Ein CRC gleich Null aus Null-Daten entsteht unabhängig vom Generatorpolynom grundsätzlich, wenn der CRC-Startwert gleich null ist und die Bits des resultierenden CRC nicht invertiert werden. Dieses Problem kann somit vermieden werden, indem ein Startwert ungleich null festgelegt wird oder aber auch die resultierenden CRC-Bits invertiert werden.

Der bekannte CRC-32 verwendet sowohl 1111... als Startwert als auch ein inverses Ergebnis. Bei CRC-16 wird ebenfalls meist 1111.. verwendet, das Ergebnis jedoch nicht invertiert. In beiden Fällen bleibt die Reihenfolge der CRC-Bits unverändert.

Auch dient bekanntermaßen die richtige Wahl des Initialisierungsvektor/Polynom zur Erkennung von CRC Fehlern:
Erkannte Fehler

Ist das CRC-Polynom gut gewählt, können mit dem oben beschriebenen Verfahren alle Einbitfehler, jede ungerade Anzahl von verfälschten Bits, sowie alle Bündelfehler der Länge \leq r erkannt werden, wobei r der Grad des CRC-Polynoms ist. Zusätzlich werden alle Fehler (also auch unabhängige Vierbit-, Sechsbit-, Achtbitfehler, u.s.w.) erkannt, deren Polynomdarstellung einen kleineren Grad als das CRC-Polynom hat. Zweibitfehler werden entgegen der landläufigen Meinung nicht grundsätzlich erkannt. Warum das so ist bzw. wie das CRC-Polynom zu wählen ist, folgt aus den kommenden Überlegungen.

Sei G(x) das CRC-Polynom (Generatorpolynom) und T(x) die Polynomdarstellung der um den CRC-Wert erweiterten zu übertragenden Bitfolge. Wenn ein Fehler bei der Übertragung auftritt, kommt (in Polynomdarstellung) beim Empfänger nicht T(x), sondern T(x)+E(x) an. Die zu E(x) gehörende Bitfolge hat an jeder Bitposition, die bei der zu übertragenden Bitfolge invertiert bzw. verfälscht wurde, eine 1. Wenn der Empfänger die um den CRC-Wert erweiterte Bitfolge erhält, berechnet er (T(x)+E(x))/G(x). Da T(x)/G(x)=0 (per Definition von T(x)), ist das Ergebnis E(x)/G(x).


Auf der Seite sind auch alle "bekannten" Polynome aufgeführt. (ganz unten)
http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
12.03.2014, 20:14 Uhr
rm2
Default Group and Edit
Avatar von rm2

Hallo an alle,


Zitat:
Letztlich haben die Programmierer "ihre" Version programmiert

Da ich die EPROM-Prüfsummenprogramme in den audatec Testrechner 1 einbauen will, sollten die wichtigsten dabei sein.


mfg Ralph
PS
mit dem audatec TR1 und einer anderen VLA kann ich auch normale K 1520 Platinen testen
--
.
http://www.ycdt.net/mc80.3x . http://www.ycdtot.com/p8000
http://www.k1520.com/robotron http://www.audatec.net/audatec
http://www.ycdt.de/kkw-stendal

Dieser Beitrag wurde am 12.03.2014 um 20:14 Uhr von rm2 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek