Hallo! Ich habe mal eine Frage bezüglich zum Thema Prüfsumme. Ich bekomme von LabVIEW eine Nachricht: z.B: : 1 1 A 0 1 2 3 4 1 2 3 4 \0 (Als Charakter, Leerzeichen sind hier nicht zu beachten). Jetzt lies ich die Zeichen am µC ein, und speichere sie in ein Array. Nun stell ich mir die Frage, wie ich am besten gewährleisten kann, dass die Daten richtig angekommen sind. Meine Idee wäre: Jedem Zeichen einen Wert zuweisen, und im LabVIEW diese Checksum hinzuzufügen, damit die Nachricht z.B. so aussieht: : 1 1 A 0 1 2 3 4 1 2 3 4 55 \0 Im Mikrocontroller Zeichen einlesen, ebenfalls Werte zuweisen, und die letzte Summe überprüfen, aber wäre ja auch irgendwie ne dumme Methode, oder was sagt ihr? Dann hab ich den Tipp gehört, dass das Ganze am besten mit einer XOR Verknüfung zu realisieren ist, wobei ich jedoch nicht genau weiß, wie das mit XOR funktionieren soll... LG
Johnny Knot schrieb:
> Meine Idee wäre: Jedem Zeichen einen Wert zuweisen,
Die Idee ist grundsätzlich gut.
Diesen 'Wert' gibt es sogar schon.
Es ist der ASCII Code des Zeichens (google anwerfen)
Karl heinz Buchegger schrieb: > Johnny Knot schrieb: > >> Meine Idee wäre: Jedem Zeichen einen Wert zuweisen, > > Die Idee ist grundsätzlich gut. > Diesen 'Wert' gibt es sogar schon. > Es ist der ASCII Code des Zeichens (google anwerfen) D.h. ich weise ':' 58dez zu, 'A' dann eben 65dez usw... Aber nur ein Problem wäre da glaube ich noch, wenn z.B. zwei Character vertauscht wären --> Prüfsumme würde stimmen, nur Nachricht wäre falsch :-/ LG
Johnny Knot schrieb: > Dann hab ich den Tipp gehört, dass das Ganze am besten mit einer XOR > Verknüfung zu realisieren ist, wobei ich jedoch nicht genau weiß, wie > das mit XOR funktionieren soll... XOR ist auch im Prinzip eine Art "Summe", nur das man anstelle von '+' halt (z.B. in C) die '^' XOR Verknüpfung nutzt. Wie das geht hängt von der verwendeten Programmiersprache im µC ab, in Labview findet man sicherlich in google wie dort eine XOR verknüpfung genutzt wird. Johnny Knot schrieb: > Aber nur ein Problem wäre da glaube ich noch, wenn z.B. zwei Character > vertauscht wären --> Prüfsumme würde stimmen, nur Nachricht wäre falsch Dann hast du ganz andere Probleme... Wenn du nichtmal sicherstellen kannst das einzelne bytes (die kleinste Framegröße) in korrekter Reihenfolge eintreffen ist irgednwas faul.
> Wie das geht hängt von der verwendeten Programmiersprache im µC ab, in > Labview findet man sicherlich in google wie dort eine XOR verknüpfung > genutzt wird. Ja danke. ^ (Bitweise XOR) wäre die Problemlösung. > Johnny Knot schrieb: >> Aber nur ein Problem wäre da glaube ich noch, wenn z.B. zwei Character >> vertauscht wären --> Prüfsumme würde stimmen, nur Nachricht wäre falsch > Dann hast du ganz andere Probleme... Wenn du nichtmal sicherstellen > kannst das einzelne bytes (die kleinste Framegröße) in korrekter > Reihenfolge eintreffen ist irgednwas faul. Nein, die Bytes treffen in korrekter Reihenfolge ein, das ist der Fall. Aber obwohl es so nutzlos klingt, soll es gewährleistet werden :-) LG
Johnny Knot schrieb: > Nein, die Bytes treffen in korrekter Reihenfolge ein, das ist der Fall. > Aber obwohl es so nutzlos klingt, soll es gewährleistet werden :-) Dann muss jedes Byte eine Sequenznummer erhalten, was die nutzbaren bits entsprechend reduziert und eine Maximale Nachrichtenlänge bedingt... Es ist natürlich nicht nutzlos, aber auf byte ebene ich sag mal ungewöhnlich...
Läubi .. schrieb: > Johnny Knot schrieb: >> Nein, die Bytes treffen in korrekter Reihenfolge ein, das ist der Fall. >> Aber obwohl es so nutzlos klingt, soll es gewährleistet werden :-) > Dann muss jedes Byte eine Sequenznummer erhalten, was die nutzbaren bits > entsprechend reduziert und eine Maximale Nachrichtenlänge bedingt... > Es ist natürlich nicht nutzlos, aber auf byte ebene ich sag mal > ungewöhnlich... Okay. Ja es ist in meiner Anwendung im Prinzip fast nutzlos. Aber was soll man gegen eine Aufgabenstellung vom Professor sagen...
Johnny Knot schrieb: > Okay. Ja es ist in meiner Anwendung im Prinzip fast nutzlos. Aber was > soll man gegen eine Aufgabenstellung vom Professor sagen... Nochmal mit dem Prof. sprechen, nachfragen was der Hintergrund ist, was sich davon versprochen wird und damit zeigen das man schonmal über das Problem nachgedacht hat ;) Was ist den die Aufgabe, ist das eine Übungsaufgabe? Oder hat das mehr Hintergrund?
Läubi .. schrieb: > Johnny Knot schrieb: >> Okay. Ja es ist in meiner Anwendung im Prinzip fast nutzlos. Aber was >> soll man gegen eine Aufgabenstellung vom Professor sagen... > Nochmal mit dem Prof. sprechen, nachfragen was der Hintergrund ist, was > sich davon versprochen wird und damit zeigen das man schonmal über das > Problem nachgedacht hat ;) > Was ist den die Aufgabe, ist das eine Übungsaufgabe? Oder hat das mehr > Hintergrund? Werde mal mit dem reden... ...mehr oder weniger Übungsaufgabe, Hintergrund hat es nicht wirklich glaub ich :-)
Ich glaube eher, du hast die Aufgabenstellung etwas fehlinterpretiert ;) Eine Checksumme zum sicherstellen des korrekten Empfangs ist nichts ungewöhnlich. Aber gegen das vertauschen von Bytes sichert eine Checksumme eigentlich nicht ab. Das is auch nicht nötig, da auf der Leitung keine Bytes ihre Position tauschen können. Die Checksumme soll gegen das absichern, was auch passieren kann: Das einzelne Bytes durch Bit-Fehler verändert werden.
Eine Prüfsumme hat immer das Problem, dass man grudsätzlich nicht 100% sicherstellen kann, dass jede Änderung detektiert werden kann. Es gibt Verfahren, die sind für die häufigsten Fehler empfindlicher und es gibt welche die sind es nicht, tun aber trotzdem ihren Dienst. Das Problem ist eng verwandt mit dem Problem der Kompremierung. Wenn Prüfsummen nämlich eindeutig wären, könnte man sie super für Kompressionszwecke benutzen. Man schickt die Länge der Daten und die Prüfsumme (anstelle der Daten) und der Empfänger spielt einfach Bytes durch, bis er die Kombination hat, die die vorgegebene Prüfsumme ergibt :-) Eine Prüfsumme wirft Informaton weg und damit ist klar, dass es immer Fälle geben wird (egal wie die Prüfsumme gebildet wird), bei der unterschiedliche Sequenzen dieselbe Prüsumme ergeben. Mann kann nunmal nicht 100 Bits (welche die Daten darstellen) in nur 16 Bit zusammenquetschen (die Prüfsumme) ohne dass etwas verloren geht.
Klaus schrieb: > Die Checksumme soll > gegen das absichern, was auch passieren kann: Das einzelne Bytes durch > Bit-Fehler verändert werden. Bei einfachem aufaddieren kann man nicht merken, ob das fehlerhaft gesetzte Bit im 1. oder 2. Zeichen auftritt. Dafür gibt es aber noch andere Prüsummenverfahren (zum Beispiel Einführung einer Gewichtung). Am elegantesten wäre eine CRC-Prüfsumme. So machen es die 1-Wire-Devices: http://www.phanderson.com/PIC/16C84/crc.html
>>> --> Prüfsumme würde stimmen, nur Nachricht wäre falsch :-/ Ah, der Konjunktiv.... ;-) Es könnte auch ein Asteriod auf die Erde fallen... Es wäre schon, wenn ich Millionär wäre... Den allermeisten auf der Welt reicht diese XOR-Prüfsumme aus. Denn in der Regel ist ein System so ausgelegt, dass fehlerfreie Daten kommen. Und einfach nur ein Fehler gemeldet wird, wenn was mit den Daten offensichtlich nicht stimmt. Es würde mich wundern, wenn deine Anforderungen so grundsätzlich strenger wären. > Aber gegen das vertauschen von Bytes sichert eine > Checksumme eigentlich nicht ab. Richtig, das kann dann nur ein Softwareproblem sein. Und wer garantiert, dass nicht gerade deine Prüfroutine einen solchen Softwarefehler beinhaltet :-o
Lothar Miller schrieb: > Richtig, das kann dann nur ein Softwareproblem sein. Und wer garantiert, > dass nicht gerade deine Prüfroutine einen solchen Softwarefehler > beinhaltet :-o Genau, daher CRC in Hardware und zur Kontrolle nochmal in Software. Zur Sicherheit gleich mit verschiedenen Prüfsummenverfahren.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.