mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenübertragung, software-technisch, tipps?


Autor: Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"zuerst muss ich das signal ja mit einer CRC 32
prüfung versehen und dann auf den pc übertragen und speichern."

Wer sagt das?

Autor: Jens123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

fuer mich ist das eher ein C Code.

Mfg

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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

Autor: Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus_8051 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus_8051 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.