CRC-Check in VHDL und C#

Edit: Es wären auch 2 Byte frei um ein CRC16 mit zu senden

Einen CRC32 findest du in jedem Ethernet-Core, und da auch immer mit dem 
gleichen Polynom. Bei so wenigen Daten macht's wohl Sinn, ihn über die 
ganze Sequenz zu berechnen/mitzuführen.
Vorsicht, bei CRC16, da gibts auch eine "kaputte" Variante, die fast 
gleich aussieht, da auf jeden Fall die CRC16-CCITT-Variante nehmen.

Oh, erst jetzt richtig gelesen: Den CRC32 müsstest du dann wohl auf ein 
Byte runter 'verhashen'.

Und eine VHDL Version kann man hier erstellen:
http://www.easics.com/services/freesics/crctool.html

Anstatt einer CRC kannst du auch einfach eine Prüfsumme bilden. Es 
werden alle übertragenen Bytes aufsummiert und dabei die Überläufe auf 
höherwertige Bytes ignoriert. Das Summenbyte wird dann als letztes Byte 
übertragen.
Das ist nicht ganz so sicher wie eine CRC aber für deine Zwecke allemal 
gut genug. (Wird z.B auch bei Modbus-ASCII verwendet).

Andi

Lothar M. schrieb:
> Du hast aber sinnvollerweise schon den SPI Master im RPi und den Slave
> im FPGA?

Jap, das funktioniert auch ohne Probleme und wahrscheinlich wird der 
Fehlerzähler auch auf 0 bleiben, aber zum lernen und verstehen und für 
eine erhöhte Sicherheit kann es nicht so schlecht sein das mal zu machen 
dachte ich mir.

Strubi schrieb:
> Einen CRC32 findest du in jedem Ethernet-Core

Eine Ethernet FCS ist keine "astreine" CRC. Sie arbeitet minimal anders 
als ein purer CRC-Algorithmus.

Solltest du die 4 Byte für die CRC übrig haben ( kannst auch beide 
hälften x-odern, dann hast du eine 16 bit Prüfsumme, die allerdings eine 
geringere Hammingdistanz hat)

Diser VHDL Core funktioniert für eine Ethernet FCS:

https://github.com/pabennett/ethernet_mac/blob/master/source/CRC.vhd

C Code (Geht auch in C#, mit eventuellen minimalen Änderungen):

http://www.edaboard.com/thread120700.html

1. Antwort

Beide Code Snippets habe ich selbst getestet und arbeiten wie gefordert.

Lothar M. schrieb:
> niemals
> tatsächlich in der Hardware brauchen

Macht man einen CRC-Check nicht auch um Fehler die durch äußere 
Störeinflüsse auf die Leitung ect. im schlimmsten Fall erkennen zu 
können oder hab ich da was vertauscht?

Ich habe es jetzt gelöst mit CCRC16-CCIT X-Modem,
für den FPGA mittels dem hier bereits erwähnten link:
http://www.easics.com/services/freesics/crctool.html
für den Raspberry in C# durch das einbinden dieses Codes in mein 
Programm:
http://www.sanity-free.com/133/crc_16_ccitt_in_csharp.html
und zum Nachrechnen habe ich mir ein Excel-Sheet erstellt bzw. diese 
Internetseite benutzt:
https://www.lammertbies.nl/comm/info/crc-calculation.html

Das einzig "komische" ist das bei der C# Funktion die beiden Bytes des 
CRC-Wertes Exakt vertauscht sind. Das habe ich aber durch vertauschen 
der Bytes vor dem vergleichen mit dem mitgesendeten CRC-Wert gelöst.

Lothar M. schrieb:
> little und big endian

Wäre dann nicht das CRC-Ergebnis ein ganz anderes. Die Daten die ich in 
die C#-Funktion übergebe sind auf jedenfall Richtig herum, diese habe 
ich mir ausgeben lassen. Leider verstehe ich die Bildung des CRC-Wertes 
innerhalb der Funktion noch nicht ganz weshalb ich nicht weis woher der 
Dreher kommt.

Aber Sie haben recht, dass das nicht das Lernziel sein kann aber bis ich 
die Lösung gefunden habe ist es für mich eine akzeptable zwischenlösung.

Gebe ich in die CRC-Funktion den gesamten Datenstrom (mit mitgesendetem 
CRC), so kommt als Ergebnis immer 0. Dies ist ja auch korrekt. Ich 
glaube der "Fehler" entsteht dadurch das die C# Funktion den CRC-Wert 
als unsigned short berechnet und dann mit der Methode 
BitConverter.GetBytes in zwei Bytes umwandelt. Diese macht zum Beispiel 
aus dem Wert 15 die Bytes 0F-00, also stellt das LSByte nach vorn.