hallo, kann mir jemand helfen, bzw. tips geben wie ich vorgehen kann bzw. soll. Und zwar habe ich die aufgabe, ein digitales signal, was mir von einem ad wandler in einem µC zur verfügung gestellt wird, in 32 bit blöcken zu transferieren. zuerst muss ich das signal ja mit einer CRC 32 prüfung versehen und dann auf den pc übertragen und speichern. Habe mich schon in die crc fehlerdiagnose eingelesen und denke das ich sie verstanden habe. Wie ich das aber software technisch realisieren kann jedoch nicht. Habe gelesen das man das auch per hardware tun kann mit einem register, dazu fehlt mir aber der weg bzw. wie man überhaupt an die sache dran gehen sollte. Das was ich an infos zu crc gelesen habe hat nur erklärt wie sich die crc zusammen setzt und wie man nach fehlern prüft, jetzt würde mich mal interessieren wie ich es den software technisch realisieren kann. Es muss ja nicht sofort eine crc 32 sein zum einstieg und zum verstehen würde auch eine crc 8 genügen, habe bis dato mit VB programmiert, für mein jetziges vorhaben müsste ich aber mit C oder Assambler programmieren, da die daten sich in einem µC befinden, oder? Deshalb meine bitte, kann mir jemand tipps odder bespiele posten , oder wie ich überhaupt anfangen könnte um endlich mal anzufangen zu können. Wäre über jede hilfe dankbar. Mit freundlichen Grüßen Claudius
"zuerst muss ich das signal ja mit einer CRC 32 prüfung versehen und dann auf den pc übertragen und speichern." Wer sagt das?
ich =) klinngt irgendwie unlogisch, wenn cih mir das so ueberlege.. ich messe etwas, pruefe ob es ricgtig ist und sende es dann nur woher soll das pruefbit kommen?? aus den AD Wandler?? aber warum sendet dann das UART wenn gewuenscht das CRC Bit??
hallo, was ich nicht verstehe ist: aber warum sendet dann das UART wenn gewuenscht das CRC Bit?? was ich vergessen habe zu sagen ist, das dieses system quasi wie ein daten loger funktionieren soll. die daten werden zunähst auf einen µC gespeichert und dann möchte ich vom µC die daten an den pc senden und dazu brauche ich, bzw möchte ich das mit der crc prüfung machen. nur woher soll das pruefbit kommen?? aus den AD Wandler?? ich definiere doch vorher ein prüfpolynom der dem sender und empfänger bekannt ist, oder nicht? ich möchte doch blockweise übertragen. ist mein gedankengang falsch???
Hier verwechselt jemand Parity bit eines Bytes mit CRC check eines
Datenübertragungsblocks
Hier hast du ein Beispiel für CRC16
crcval = 0;
for (sm_cnt = 0; sm_cnt <= sm_input_buffer_pointer; sm_cnt++)
{
c_crc = sm_input_buffer[sm_cnt];
q_crc = (crcval ^ c_crc) & 017;
crcval = (crcval >> 4) ^ (q_crc * 010201);
q_crc = (crcval ^ (c_crc >> 4)) & 017;
crcval = (crcval >> 4) ^ (q_crc * 010201);
}
Es geht auch mit einem Lookup Table, dann ist die Berechnung schneller.
hallo, danke für deine hilfe, so wie ich das erkennen kann ist das assambler sprache. verstehe denn code nicht, kannst du mir vielleicht, durch kommentare erklären was da passiert bzw abläuft? wäre echt nett, danke sehr du hast recht, habe ganz vergessen, wenn ich crc32 check mache, dann wäre der crc32 check schon maximal 32 bit gross, bzw. der rest der division die ich an meine daten anhänge. trotzdem meine ich crc, gibt es vielleicht eine optimale datengrösse die ich mit dem crc32 harmoniert, oder kann die datenlänge unendlich gross sein? bei den infos die ich gelesen habe stand davon nichts. Claudius
Das ist C Code. Assembler nutze ich nur in Notfällen wenns gar nicht mehr anders geht (zB. AVR Bootloader) Ich habe glaube ich auch irgend wo ein Beispiel in Assembler. Wenn ich es finde werde ich es hier posten. Zu deiner Frage der Grösse des Datenübertragungsblocks, ich würde sagen die Grösse soll angemessen sein. Soll heissen, wenn bei der Übertragung ein Fehler passiert ist, muss der Block ja wiederholt werden. Je nach Übertragungsgeschwindigkeit kann das kürzer oder länger dauern. Also sollte es für deine Anwendung abgestimmt sein.
Über die UART wird oft nur das Parity-Bit verwendet. Wenn man eine CRC verwendet, dann sind bis zu 256 Byte eine 8-Bit CRC und bis 64kB eine 16-Bit CRC üblich. Auf der Maxim Webseite findest Du eine CRC-Application Note für deren 1-Wire Devices. Peter
hallo, danke erstmal für eure hilfe, so wie es aussieht haben sich noch nicht viele mit der crc32 auseinandergesetzt bzw mussten es nicht. weiss keiner wieviel kB bei einer 32-bit crc üblich wären? zu dem code, kann den nicht entziffern, sehe da nur eine for schleife aber was die genau macht ist mir nicht klar, verstehe auch die abkürzungen der variabeln nicht, damit ich mir irgendwas vorstellen kann. bzw kann ich auch kein C, das wirds wohl sein. wäre jemand bitte so nett und könnte mit den code mal kommentieren? was mich auch sofort interessieren würde, wäre wie der dazu gehörige code lauten würde um eine übertragung, wenn sie falsch wäre noch einmal anzufordern? so was gibt es bestimmt irgendwo aber ich weiss wirklich nicht wo. ich war auf der maxim seite konnte mich aber nicht so richtig durch kämpfen, da mein englisch sehr schlecht ist, vielleicht würde mir der genaue link helfen?? danke an alle claudius
Hallo Claudius, Du schreibst, daß Du die Daten in Blöcken zu 32 bit übertragen möchtest. Um in einem 32bit langen Datenblock die Richtigkeit der Daten sicherzustellebn, dazu ist eine 32bitCRC wirklich überdimensioniert. Das würde ja bedeuten, daß Du in jedem Block an die 32bit Nutzdaten noch einmal 32bit Prüfsumme anhängen und mitübertragen mußt. Von daher reichen bei 32bit Nutzdaten auch ein 8bit langer CRC. Kommentieren möchte ich den Code der CRC-Routine wirklich nicht, dazu sollte GOOGLE im Internet genug finden. Vielleicht versuchst Du auch erstmal ein einfacheres Prüfverfahren (Summe oder XOR), sollte bei deinen 32 bit reichen. Damit der µC erkennen kann, ob der PC die Daten korrekt empfangen hat, mußt Du Dir noch ein Protokoll ausdenken. Auf jedenfall muß der PC nach jedem empfangenen Block dem µC antworten, ob der Block o.k. war oder nicht. Denk daran, daß auch diese Rückmeldung gestört werden könnte, oder gar verloren geht. Evtl. ist es sinnvoll, jedem Block der übertragen wird eine aufsteigende Nummer zu geben. evtl. so: µC an PC: Blocknummer (1 byte) Status (1Byte) (z.B.:normal 0, 1 für erste Neusendung, 2 für 2. usw.) Nutzdaten (4Btes) CRC8 (1Byte) (oder sonstige Prüfsumme) PC an µC: Blocknummer (1Byte) Status (1Byte) (z.B.: 0=O.K., 1=CRC fehler, 2=Block fehlte, 3=...) So, jetzt viel Spaß beim Programmieren
noch was zur CRC: nicht alle Verfahren zur CRC-Berechnung sind kompatibel. Auch wenn das gleiche Polynom verwendet wird, kann es doch zu unterschiedlichen CRC-Werten kommen, wenn die Daten anders berechnet werden. So verschieben manche Prozeduren die Bits nach links, andere nach rechts, manche initialisieren sich mit Startwert 0 andere mit FF usw. Da Du aber Sender und Empfänger selbst programmierst, sollte es hier keine Probleme geben, wenn du bei beiden den gleichen Code verwendest. Gruß, Markus_8051
hallo, danke erstmal für euren support! habe gerade nach CRC kommentierung mit google gesucht aber nichts gefunden, wahrscheinlich gebe ich die falschen stichwörter ein. wenn jemand ein link kennt wo ein crc code mit kommentierung, zur nachvollziehung steht, bitte posten. mfg claudius
Was fehlt dir denn nun genau zum Verständniss? Wie Markus_8051 schon geschrieben hat, sind es zwei unterschieldiche Dinge die du angefragt bzw. die bei deinem Projekt anstehen: 1: Ein Datenstrom (also deine Meßdaten) müssen von A nach B gebracht werden. Damit da nichts verloren geht, ist (wie schon erwähnt) eine "wie auch immer geartete" Form von Quittungsmechanismus (neudeutsch: handshake) notwendig, damit B mitbekommt, das nicht alles von A angekommen ist. Neben den reinen Nutzdaten wird also noch irgendein Blockzähler oder ähnliches sinnvoll sein. 2: Die zu übermittelnden Daten möchtest du "besonders sorgfältig" übermittelt wissen. Um Verfälschungen zumindest zu erkennen(möglicherweise zu korrigieren, auch das ist möglich) gibt es verschiedene Verfahren. Wenn nur "Einzelfehler" aufträten, dann könntest du mit einer simplen Quersummen-Zählung der vorhandenen "0" oder "1" in deinem Datenwert schon mal etwas anfangen (dies entspricht genau dem Parity-bit): Wenn dein Datenwort als Quersumme "0" hat, wird dieses Bit nun als Parity-Bit mit auf die Reise gebracht. Wenn es nun auf Transportweg zu einem Verfälschen der Daten kommt (irgendein Bit wird zerstrubbelt übertragen und anstelle einer 0 eine 1 eingelesen) so meldet der Empfänger (bzw. ein auslesendes Programm): "Menno, das übermittelte Datenwort sollte als Quersumme eine 0 haben, ich komm aber auf eine 1" --> PArity error, Übermittlungsfehler. Bei 2 Bits, bei denen das zufälligerweise passiert (im gleichen Datenwort)hast du mit einem simplen Paritybit verloren: Doppelfehler können nicht erkannt werden. Es gibt nun mehr oder weniger komplexe(re) Verfahren, zyklische Prüfsummen (cyclic redundancy check) über kleine oder Große Datenpakete zu erstellen, aber bei deinen "paar bits" die du übermitteln willst, sind "intensive" Fehleridentifikations- und Korrektur-Algorithmen wahrscheinlich "oversized". (Hinweis: Bei digitaler SAT-Übertragung ist die "Luft-Schnittstelle" ziemlich störanfällig. Dort wird mit einem Verhältnis von 5/6 oder sogar 3/4 gearbeitet, d.h. 1/6 oder 1/4 der übermittelten Gesamt-Daten sind CRC Daten zur Fehlererkennung und Korrektur!) Da du jedoch deine Daten bei einer Verfälschung von "A" nochmal anfordern kannst , wäre ein etwas einfacherer Algorithmus wahrscheinlich sinnvoller. Mein Vorschlag: Kümemrer dich erstmal um die grundsätzliche Handshake-Thematik (wie oben unter 1. erwähnt), und versehe deine Nutzdaten mit einemeinfachen parity-bit, welches du mit übermittelst. Wenn das alles prima funktioniert, dann kannst du einen komplexeren CRC ermitteln, und mit übermitteln. Wenn du es dan ganz schön gemacht hast, dann hast du sogar einen algorithmus implementiert, welcher dir anhand der übermittelten CRC-Daten eine Fehlerkorrektur ermöglicht. Google mal unter den stichworten einzelfehler doppelfehler CRC Ich habs grad mal gemacht und sehe da 29 Links, welche alle das Zeugs in deutscher Sprache beschreiben .... PS: Und berichte uns von deinen Fortschritten, wir freuen uns imemr über Rückmeldung für Hilfe.
Um noch auf diene Frage zurück zu kommen: "aber warum sendet dann das UART wenn gewuenscht das CRC Bit??" Na ja, es spricht nichts dagegen daß mehrere Stellen Prüfverfahren nutzen, z.B. 1. Du "beprüfsummst" dein Nutzdatenwort mit irgendeinem CRC 2. Dann packst du diese Daten zusammen mit einem Sequenzzähler und z.B. noch einer Empfängeradresse (sofern es eine solche gäbe) zu einem weiteren Datenpaket zusammen und versiehst es wiederum mit einer CRC 3. Das übermittelde UART weiß natürlich nicht welche Daten es da inhaltlich übermittelt. Vereinbarungsgemäß stellst du z.B. eine serielle Schnitte ein auf 9600,e,8,1 was bedeutet: 9600bps, Even Parity, 8 bit pro übermitteltem "Päckchen", gefolgt von einem Stopbit. Somit wäre dann schon mal auf niedrigster Transportebene ein gewisser Schutz (vor Einfachfehlern in einem byte) gegeben. Solche Parity-Bits sind hardwaretechnisch recht leicht zu generieren, und waren sicherlich in der Computer-Steinzeit ein preiswertes Mittel, um nicht vorhandene softwaretechnische CRC-Polynome zu ersetzen
Thread beobachten
Seitenaufteilung abschaltenBitte 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.