Hardware CRC in Paketen

[Fritz R. (f_richter)]

Hallo,
die meisten modernen Prozessoren besitzen ja Hardware CRC Einheiten, die 
sich praktischerweise an diverse Komunikationseinheiten wie Uart und SPI 
ankoppeln lassen. Auf den ersten Blick eine geniale Sache, auf den 
zweiten Blick ergibt sich aber ein Problem, für das ich bisher keine 
Lösung gefunden habe.
Wenn ich per DMA ein Packet mit einer definierten Länge übertrage, also 
z.B. START,COMMAND,DATEN,CRC wird ja die CRC automatich mit in die 
errechnete CRC eingerechnet, was ja so nicht funktionieren kann.
Damit ergibt sich der ungünstige Weg, DMA Transfer zwei Byte kürzer 
(ohne CRC), im "DMA Block done" Interrupt die CRC nochmal berechnen und 
noch einzeln senden. Beim Empfang ergibt sich dann das gleiche Problem.
Irgendwie kann ich nicht glauben, das das nicht zumindest auf einer 
Seite einfacher geht.
Könnte man auf Empfäger Seite die CRC einfach um die zuviel emfangenen 
und einberechneten 2 Bytes zurückrechnen, oder gibt es noch eine Methode 
an die ich bisher nicht gedacht habe?
Ich hoffe ich hab mich einigermaßen verständlich ausgedrückt.

[Hannes J. (pnuebergang)]

Tschuldigung, aber was soll der Blödsinn? Natürlich kannst du eine CRC 
nicht einfach per DMA-Blocktransfer wie die Paketdaten von der Quelle 
lesen, wenn sie erst beim Blocktransfer selbst berechnet wird.

Je nach DMA-System musst du nach Ende des Blocktransfers, die beim 
Blocktransfer berechnete CRC manuell nachschieben, oder du hast ein 
DMA-System, dass die CRC Bytes automatisch nachschieben kann.

Einfach beim DMA-Transfer zuerst mal eine irgendwie vom Himmel gefallene 
Scheisdreck-CRC mitsenden und dann noch eine über den gesamten Block 
automatisch berechnete zweite CRC hinterherschieben ist ja wohl gaga.

[Fritz R. (f_richter)]

Vielen Dank für die Antwort.

Hannes Jaeger schrieb:
> oder du hast ein
> DMA-System, dass die CRC Bytes automatisch nachschieben kann

An sowas dachte ich schon, gibts denn so etwas?
Was ja auch schon reichen würde, wäre eine CRC Unit, die einfach bei 
Blocklänge n-2 mit der CRC Berechnung stoppt, geht aber zumindest bei 
meiner nicht.
Eine Idee ist mir allerdings schon gekommen, einen zweiten DMA channel 
parallel zum ersten mit Länge -2 starten, der nur die CRC Unit befüllt.
Naja getestet ist es noch nicht, könnte aber funktionieren.

Viele Grüße

[CRC (Gast)]

In Empfangsrichtung kannst du die empfangene CRC mit in das CRC-Modul 
schieben. Wenn am Ende des Datenpakets (mit CRC) eine 0 im CRC-Register 
steht, wurde die Nachricht richtig übertragen.

Eine Eigenschaft der CRC ist: Daten+CR = 0. (Das + ist hier nicht im 
mathematischen Sinne zu verstehen!)

Im Klartext: Über ein Datenpaket wird eine CRC x berechnet. Hängt man 
diese CRC x an das Datenpaket dran und berechen wieder die CRC (über das 
Datenpaket+CRC x), so kommt '0' heraus.

[Fritz R. (f_richter)]

Hallo,
Danke ! genau das habe ich gesucht, ich glaube das schonmal gehört zu 
haben.
Auf der Sendeseite habe ich kein Problem die zwei CRC Bytes manuell 
anzuhängen.
In DMA Block done Interrupt ist es aber lästig noch auf zwei Bytes zu 
warten, nur um zu prüfen ob das Paket auch ok. war.

[Andreas D (Gast)]

Unabhaengig von der vorherigen Diskussion ob das nun noetig ist oder 
nicht:

Also mit CRC geht viel mehr, als die meisten glauben:

> Könnte man auf Empfäger Seite die CRC einfach um die zuviel emfangenen
> und einberechneten 2 Bytes zurückrechnen,

Das ist ziemlich einfach.

In manchen Faellen (PCI liest vom memory) kann aus auch vorkommen, dass 
die Daten in der falschen Reihenfolge bei der CRC-Unit vorbeikommen.
Auch das laesst sich korrigieren.

Schliesslich kann es auch sein, dass man die Daten mit 16- oder 32-bit 
verarbeiten muss, aber manchmal ein oder mehrere untere Bytes ignoriert 
werden muessen.
Auch das laesst sich korrigieren, das ist dann aber eher etwas fuer die
FPGA Fraktion.

Andreas