Hallo Leute, ich habe eine Kommunikation zwischen PC und µC via RS-232. Meine Daten sehen wie folgt aus: STARTBYTE | ID | Datenlänge n | DATEN[0...n-1] | Prüfbyte | STOPBYTE Nun habe ich das Problem, dass manchmal ein Byte falsch gesendet wird. Ich sende testweise immer 3 Bytes als Daten 11 21 31. Manchmal kommt anstatt der 11 eine 0. Woher könnte das kommen, und wie kann ich Pakete mit einer 0 anstatt einer 11 entlarven?
Gast
#2524683
Sollte diene Prüfsumme nicht genau dafür da sein, um Übertragunsfehler zu erkennen? Übertragungsfehler sind ganz normal. Deshalb implementiert man mechanismen, z.B. CRC, um so etwas zu erkennen. Wie wird der Takt für RS232 im uC erzeugt? wenn es genau sein soll, wird gerne ein passendes Baudratenquarz oder Fraktalgenerator verwendet.
Gast
#2524690
Die Ursache des Fehlers ist die asynchrone Übertragung. Ohne Synchronisation ist die Abtastrate von Quelle und Senke immer unterschiedlich, was sich als Übertragungsfehler auswirkt.
Also Takt gibts von einem 16MHz Quarz. Die Prüfsumme ist bis jetzt noch nicht implementiert. Die habe ich nur schon mit hingeschrieben, weil meine Frage darauf abzielt, eine solche einzuführen. Ich weiß nur leider nicht genau wie. Ich denke bereits über eine CRC8 nach, habe aber noch nicht verstanden, wie ich diese auf ca. 25Bytes anwenden kann?
Gast
#2524725
Was für ein Kontroller? Hat der einen Fraktalgenerator? Normalerweise wird die Taktrate mit einem Teiler eingestellt, der in einem Register abgelegt wird. In den Handbüchern ist meistens eine Formel angegeben, mit der man die Fehlerrate berechnen kannst. Was für einen Controller verwendest du? Du solltest mehr Informationen bereitstellen, was du machen willst. Als nächstes musst du wissen, welche Fehlerrate akzeptabel ist. Du musst dir auch überlegen, welche Fehler vom Übertragungsverfahren selbst korrigiert oder nur erkannt werden sollen. Ja nach Randbedingungen würde z.B. ein Paritybit ausreichen. Zu CRC steht eigentlich bei Wikipedia genug, wo genau liegt dein Problem? Du nimmt einfach deine 25Byte als lange Zahl und führst die Polynomdivision durch. Relevant ist auch, was bei einem Fehler passieren soll. Sollen die Daten nochmals gesendet werden oder nur die fehlerhaften weggeschmissen?
Also verwendet wir ein PIC18F6620. Takt wird über Register eingestellt. Bei mir sind es 19.230 baud (+1.6%). Bei falschen Daten, sollen diese noch einmal gesendet werden. Und wegen meinem Problem mit dem CRC. Meine Frage ist da halt, wie ich diese auf mehrere Bytes anwenden kann ohne diese zu einer großen Zahl zusammen zu fassen.
@ Stephan Meter (multimeter90) >Also verwendet wir ein PIC18F6620. Takt wird über Register eingestellt. >Bei mir sind es 19.230 baud (+1.6%). Welche Taktquelle? Ein Quarz? http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART Gilt auch für PICs ;-) >Und wegen meinem Problem mit dem CRC. Meine Frage ist da halt, wie ich >diese auf mehrere Bytes anwenden kann ohne diese zu einer großen Zahl >zusammen zu fassen. Siehe CRC. Für einfachere Sachen reicht auch ein einfacher Parity Check. MFG Falk
Gast
#2525065
Hi
>Bei mir sind es 19.230 baud (+1.6%).
Bei mir 0,16%.
MfG Spess
> Bei mir 0,16%. Stimmt ;) > Welche Taktquelle? Ein Quarz? Ja wie oben geschrieben. Der Quarz läuft ohne Probleme mit seinen 16MHz, die Baudrate stimmt auch. Ich bin gerade dabei eine crc8 zu implementieren. Dann sollte das Problem gelöst sein.
spess53 schrieb: >>Bei mir sind es 19.230 baud (+1.6%). > Bei mir 0,16%. Fängt ja schon gut an... Stephan Meter schrieb: > Die Prüfsumme ist bis jetzt noch > nicht implementiert. Die habe ich nur schon mit hingeschrieben, weil > meine Frage darauf abzielt, eine solche einzuführen. Ich weiß nur leider > nicht genau wie. Die einfachste Prüfsumme wird durch eine Addition aller gesendeten Bytes gewonnen. Von dieser Summe wird dann nur das niedrigste Byte verwendet/versendet (ganz einfach, wenn zur Berechnung nur ein char verwendet wird). Diese Vorgehensweise reicht in einem Großteil der Fälle aus. Stephan Meter schrieb: > Meine Daten sehen wie folgt aus: > STARTBYTE | ID | Datenlänge n | DATEN[0...n-1] | Prüfbyte | STOPBYTE Ich hoffe, du hast soweit gedacht, ALLE Daten als ASCII-Text zu versenden... Oder überleg dir mal, was passiert, wenn dein Startbyte z.B. 0x02 ist, und du dann noch ein paar Daten hast, die ebenfalls 0x02 sind. Hast du daran gedacht? Kommt deine Software damit klar? Tilo Lutz schrieb: > wenn es genau sein soll, wird gerne ein ... Fraktalgenerator verwendet. Habe ich noch nie gehört. WIE bzw. WO wird ein Fraktalgenerator zur Baudratenerzeugung genommen? Hast du da mal eine Quelle/Link dazu?
Gast
#2525092
Hi >WIE bzw. WO wird ein Fraktalgenerator zur Baudratenerzeugung genommen? >Hast du da mal eine Quelle/Link dazu? Siehe XMegas. MfG Spess
Gast
#2525100
Hi >Ich bin gerade dabei eine crc8 zu implementieren. Dann sollte das >Problem gelöst sein. Nö. Mach erst mal deine Kommunikation ohne CRC stabil. MfG Spess
@ spess53 (Gast) >>WIE bzw. WO wird ein Fraktalgenerator zur Baudratenerzeugung genommen? >>Hast du da mal eine Quelle/Link dazu? >Siehe XMegas. Naja, zwischen einem FRAKTALGENERATOR und einem fractional baud rate generator liegen Welten, nicht nur sprachlich ;-) http://de.wikipedia.org/wiki/Fraktalgenerator MfG Falk
1 | |
Da bin ich aber beruhigt, ich meinte schon, eine grundlegende technische Entwicklung verschlafen zu haben. Das hast zum Glück mit Teilern, Teilerverhältnissen und Resten zu tun, aber absolut nichts mit Fraktalen... http://en.wikipedia.org/wiki/Fractal http://en.wikipedia.org/wiki/Fractional http://www.dict.cc/englisch-deutsch/fractal.html http://www.dict.cc/englisch-deutsch/fractional.html EDIT: Falk war schneller... ;-)
Gast
#2525108
:) OK, ihr habt mich erwischt, ich war schreibfaul. Wie oft tauchen denn Fehler auf? 0,19% sind schon mal ein guter Wert. Passt der auch zur Praxis?
Hallo, kann ich spess53 nur zustimmen. So als persöhnliche Erfahrung: ca. 20m geschirmtes Kabel zwischen 2 Rechnern in normaler Umgebung mit 38400 nie Übertragungsfehler, bei 57600 ca. alle 2-3 Minuten einen. Große Dateien mit ZModem übertragen, bei 57600 gab es dann die ersten Wiederholungen. Gruß aus Berlin Michael
naja wie gesagt, es werden nur manchmal bytes als 0 gelesen. Alles andere kommt sauber an. Auch die vermeindliche 0 kommt sauber an, sonst würde sie ja nicht erkannt.
Stephan Meter schrieb: > naja wie gesagt, es werden nur manchmal bytes als 0 gelesen. In welcher Umgebung? Alles was nicht länger als 20 Meter ist, in der Nähe keine starken Motoren hat oder über eine Telefonleitung läuft (und vielleicht noch ein paar ekelige Dinge, die mir jetzt nicht einfallen) darf überhaupt keine Übertragungsfehler aufweisen! Ansonsten hast du schlicht und ergreifend irgendwo einen Fehler. Den gilt es erst mal zu eliminieren. Vom µC zum PC auf 2 Meter Distanz mit einem sauberen Kabel, das muss bei 19200 Baud flutschen wie eine Eins.
Es sind nicht einmal ein Meter. Ich kann aber leider nicht sagen woher die 0 kommt.
Gast
#2525136
Dann such den Fehler und eier nicht mit crc und sonst was rum. Damit behebst Du den Fehler ja nicht.
Gast
#2525138
Hi >Es sind nicht einmal ein Meter. Ich kann aber leider nicht sagen woher >die 0 kommt. Dann wäre der erste Schritt die Fehlermeldung der UART auszuwerten. AVRs und PICs können z.B. Dataoverrun und Frameerror (auf Byteebene) erkennen. MfG Spess
Stephan Meter schrieb: > Auch die vermeindliche 0 kommt sauber an, sonst > würde sie ja nicht erkannt. Wenn die 0 "sauber ankommt", heißt das ja, sie wurde empfangen. Also ist der Fehler auf der Senderseite. Wenn keine 0 ankommt, ist der Fehler auf der Empfängerseite. Auf jeden Fall wird es ein Softwarefehler sein, den Du suchen mußt. Eine CRC ist der falsche Ansatz. Peter
Ich glaube es liegt an der Empfängerseite. Der Fehler tritt nur bei dem ersten empfangenen Paket auf. Und dann immer im 0.ten Datenbyte. Ich hatte am Anfang auch schon, dass ich beim ersten lesen der Schnittstelle so ca. 20 Nullen bekommen habe.
@ Stephan Meter (multimeter90) >Ich glaube es liegt an der Empfängerseite. Der Fehler tritt nur bei dem >ersten empfangenen Paket auf. Und dann immer im 0.ten Datenbyte. >Ich hatte am Anfang auch schon, dass ich beim ersten lesen der >Schnittstelle so ca. 20 Nullen bekommen habe. Klingt nach einem TX-Pin, das ab und an "runter fällt", z.B. wenn irrtümlich der UART neu initialisiert wird. Passiert auch oft bei RS485 Bussen, wenn nach dem Senden der Sender abschaltet und die richtigen Pull-Ups/Terminierungen am Bus fehlen. MFG Falk
ja, floatende Leitungen bei 485 oder zu frühes / zu spätes Umschalten des Datenflusses kann schöne Effekte erzielen. Letztes Byte abgeschnitten oder erstes Byte abgeschnitten ... Mitunter brauchen die UARTS aber auch etwas bis sie sich synchronisieren bei asynchroner Übertragung. Die CRC kann schon sehr nützlich sein. Hab gerade ne Anwendung in der Mache wo ne spezielle CRC eingesetzt wird um den Vertriebskanal des Herstellers zu schützen, sprich keine Fremdhardware an dem Bus ... grrr
Stephan Meter schrieb: > STARTBYTE | ID | Datenlänge n | DATEN[0...n-1] | Prüfbyte | STOPBYTE Stephan Meter schrieb: > Ich glaube es liegt an der Empfängerseite. Der Fehler tritt nur bei dem > > ersten empfangenen Paket auf. Und dann immer im 0.ten Datenbyte. > > Ich hatte am Anfang auch schon, dass ich beim ersten lesen der > > Schnittstelle so ca. 20 Nullen bekommen habe. Startbyte, ID und Datenlänge werden korrekt erkannt und erst Datenbyte[0]? Oder ist es immer das erste byte, welches nicht erkannt wird. Liest dein Empfänger im Interrupt?
Gast
#2525654
Stephan Meter schrieb: > Ich glaube es liegt an der Empfängerseite. In technischen Angelegenheiten ist Glaube ein Fehler den es zu beheben gilt.
Fhutdhb Ufzjjuz schrieb: > Mitunter brauchen die UARTS aber auch etwas bis sie sich synchronisieren > bei asynchroner Übertragung. Wat?!
Was ist die Empfängerseite? Der PC oder der µC? Wie liest du auf dem PC / µC Wenn es immer das gleiche Byte ist dann ist der Fehler mit großer Wahrscheinlichkeit in der Software zu suchen. Tritt er nur manchmal auf könnte es z.B. eine nicht initialisierte lokale Variable auf dem Stack sein. je nachdam was zufällig drinsteht geht es mal und mal nicht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.