Hilfe bei der Identifizierung der Prüfsumme

Ich brauche Hilfe bei der Identifizierung des Prüfsummenalgorithmus in den folgenden Paketen.

Das Paketformat lautet also:

sd ?? dd dd dd ??

s = Startnibble d = Daten (binär codierte Dezimalzahl)? = unbekannt - möglicherweise Prüfsumme

Hier sind fünf Pakete (Nummer wird in Klammern übertragen) und das tatsächliche Paket, das auf der Leitung gesendet wird, rechts hexadezimal.

(1112694): f1 f7 11 26 94 74

(5432432): f5 7c 43 24 32 a2

(6430116): f6 dc 43 01 16 48

(3254817): f3 d8 25 48 17 e9

(0042863): f0 ce 04 28 63 b2

Ich habe XOR und Summieren ausprobiert, aber sie scheinen nicht zu funktionieren. Die Pakete werden mit UART übertragen.

jede Hilfe geschätzt!

uart crc

— user3780104
quelle

Wie hängt das mit der Elektronik zusammen?

— Pipe

Um welches Gerät handelt es sich? Es könnte nur dokumentiert werden.

— Eugene Sh.

@pipe Ich würde sagen, es ist. Kommunikationsprotokolle sind eher EE als Programmierer.

— Eugene Sh.

Sie benötigen viel mehr als fünf Zufallsstichproben, um dies herauszufinden. Inwieweit können Sie den Inhalt der Übertragung steuern? Können Sie beispielsweise versuchen, 0000000, 0000001, 0000002 usw. zu senden? Ein solches Muster würde viele Hinweise liefern. Was bedeuten die Daten überhaupt?

— Dave Tweed

Meines Erachtens sollte diese Frage nicht abgeschlossen werden. Fast jeder Elektrotechniker, der im Rahmen seines Projekts an der eingebetteten Codierung beteiligt war, hatte das Problem, entweder einen CRC-Code für sein Projekt zum Laufen zu bringen oder einen CRC von etwas zurückzuentwickeln, mit dem er eine Verbindung herstellen muss. Das Überprüfen von Codes spielt in der Elektronik eine große Rolle, ob diese Codes in Hardware-, FPGA- oder Mikrocontroller-Firmware generiert und überprüft werden.

— Michael Karas

Nehmen Sie Ihre erste Datenzeile:

(1112694): f1 f7 11 26 94 74

Erstellen Sie einen Byte-Stream mit Hex-Zahlen wie folgt:

0x94

0x26

0x11

0xF1

Führen Sie diese Bytes in dieser Reihenfolge durch einen CRC-CCITT (XModem) CRC-Algorithmus, um eine CRC von 0xF774 zu erhalten. Das High-Byte der CRC geht an die zweite Position der Nachricht und das Low-Byte der CRC geht an die letzte Position der Nachricht.

Dieselbe Technik funktioniert für jede der Nachrichten in Ihrem Beispiel. Ich habe den Online-Rechner verwendet , um das Ergebnis wie folgt anzuzeigen:

Die Polynomfunktion für den CRC-CCITT-Algorithmus lautet wie folgt:

Ich überlasse es Ihnen, nach dem Quellcode für den CRC-CCITT-Algorithmus zu suchen und die spezifischen Nuancen der Verwendung dieses Codes in der alten XModem-Methodik zu verstehen. Das 0x1021-Polynom ist bekannt und ich habe es jahrelang in meinen Projekten für alles verwendet, von Kommunikationsprotokollen bis zur Überprüfung von Codes in Datensätzen, die in seriellen EEPROMs und FRAM-Chips gespeichert sind. Die Verwendungsnuancen spielen eine Rolle, ob die CRC-Felder des Pakets auf etwa 0x0000 oder 0xFFFF voreingestellt sind und ob diese voreingestellten Felder auch durch den CRC-Rechner geleitet werden, um zu einem Ergebnis zu gelangen. Beachten Sie, dass online eine Vielzahl von Informationen verfügbar ist.

— Michael Karas
quelle

Gut gemacht! Der Taschenrechner-Link könnte nützlich sein.

— Spehro Pefhany

Ha. Gute Arbeit ..

— Eugene Sh.

Ich liebe dich. Ernsthaft. Vielen herzlichen Dank. Ich hatte gerade angefangen, die Firmware zu zerlegen, um herauszufinden, wie es funktioniert !!!!

— user3780104

Hut ab für Dich. Ich glaube nicht, dass ich im zweiten Byte nach dem MSB der Prüfsumme gesucht hätte. Das ist ziemlich komisch. Und die msn mit einem F anstelle einer 0 auffüllen?

— WhatRoughBeast

@WhatRoughBeast Vielleicht soll ein Eingabewert ungleich Null für die Prüfsumme garantiert werden? Unabhängig davon ist dies eine hervorragende Arbeit von Michaels Seite.

— Adam Haun