Serielle Daten in falschen Bits empfangen

Ich habe eine RS422-Schnittstelle zwischen einem Arduino und einem benutzerdefinierten Gerät eingerichtet. Das Gerät ist so eingestellt, dass es einen 16-Bit-Header, gefolgt von 66 Datenbytes, bei einer Baudrate von 460.800 und 200 Hz überträgt. Dies kann nicht geändert werden.

Ich habe online gelesen, dass die Arduino-Serie problemlos 460.800 bps verarbeiten kann. Tatsächlich habe ich ohne Probleme erfolgreich mit dieser Baudrate zwischen MatLab und Arduino kommuniziert. Ich habe auch bestätigt, dass das Gerät funktioniert, denn wenn es direkt an den Computer angeschlossen ist, wird es gut gelesen.

Wenn ich versuche, die Daten mit dem Arduino zu lesen, bekomme ich nicht das, was erwartet wird. Der Header, den ich bekommen soll, ist 0x55AA. Ich bekomme jedoch meistens 0xD56A, aber manchmal bekomme ich Werte wie 0xB5CA. Es scheint, dass die zweite Hälfte jedes Bytes korrekt ist, aber nicht die erste, und ich habe einige Bits, die hoch und einige niedrig gehen, wenn sie es nicht sollten. Aus diesem Grund bezweifle ich die Gültigkeit der übermittelten Daten.

Kann mir bitte jemand erklären, warum dies geschieht und welche Lösungen ich versuchen kann, um dies zu beheben?

Danke

UPDATE: Ich habe mit einem Oszilloskop durchgesehen und kann sehen, dass die Wellenform als 0x55AA herauskommt, wie es sein sollte. Ich habe den seriellen Arduino-Puffer erhöht und die Platinen geändert, aber das Problem besteht weiterhin.

Ich habe es geschafft, es mit einer niedrigeren Baudrate (115.200) zum Laufen zu bringen, aber ich muss es auf 460.800 einstellen. Bei dieser niedrigeren Baudrate würde ich 0x55AA erhalten, aber sobald ich es auf 460.800 hochfahre, verliere ich diese Daten und es wird wie oben erwähnt.

Was lässt Sie glauben, dass es nur einen Grund gibt, warum Ihre beschriebenen Symptome auftreten können?
Wenn Sie Zugriff auf einen Bereich haben, ist jetzt ein guter Zeitpunkt, ihn zu verwenden.
Bekommst du jemals den richtigen Header?
@PlasmaHH Ich sage nicht, dass es nur eine Ursache gibt, ich bitte nur um eine Erklärung, warum dies geschieht und wie es behoben werden kann.
@BrianDrummond Der Bereich zeigt 0x55AA, wie es sollte.
@Tom: das scheint widersprüchlich. Sie sagen selbst, dass es keinen einzigen Grund gibt, warum dies geschieht, aber Sie möchten, dass wir Ihnen sagen, warum dies geschieht. Das Beste, was wir Ihnen geben können, ist eine Spekulation über Hunderte von möglichen Dingen, die schief gelaufen sein könnten, aber wir haben überhaupt keine Informationen über die beteiligte Hardware oder wie die Signale aussehen. Auf dieser Ebene liegt der Grund dafür darin, dass die Daten nicht korrekt von A nach B gelangen.
@Andyaka Nicht bei dieser Baudrate. Ich mache es jedoch mit einer niedrigeren Baudrate. Bei dieser Baudrate (460.800) erhalte ich 0x952A, 0xD56A usw.

Antworten (2)

Schauen wir uns zunächst die von Ihnen erwähnten Daten an:

0x55AA  0101010110101010
0xD56A  1101010101101010
0xB5CA  1011010111001010

Wie wir sehen können, sind die Daten nah dran, aber leicht daneben. Es gibt viele Gründe dafür, dass serielle Daten "leicht daneben" liegen, aber in Ihrem speziellen Fall ist die serielle Datenrate offensichtlich. Damit asynchrone serielle Daten korrekt empfangen werden, muss die ursprüngliche Uhr auf der Empfängerseite neu erstellt werden. Als Faustregel für serielle Verbindungen gilt, dass bei einer Abweichung der Taktraten von mehr als 3 % ähnliche Fehler wie die von Ihnen beschriebenen auftreten.

Bei einer Rate von 460.800 Bit/Sekunde sind das etwas mehr als 2,27 μ s pro Bit. Hier sind einige Tipps zur Fehlerbehebung:

  1. Überprüfen Sie die Bitratenuhren an beiden Enden und stellen Sie sicher, dass die Frequenzen innerhalb von 3 % voneinander liegen.
  2. Halten Sie Ihre Verkabelung so kurz wie möglich.
  3. Überprüfen Sie den Leitungsabschluss an beiden Enden, um sicherzustellen, dass er die gleiche Impedanz wie die Leitung hat.
  4. Überprüfen Sie die empfangene Wellenform mit einem Oszilloskop. Suchen Sie nach Klingeln oder langsamen Übergängen.

Sie können auch überlegen, ob das Paket einen CRC enthält, der Ihnen zumindest dabei helfen würde, einen Fehler zu erkennen.

Wie man Uhren überprüft

Lassen Sie mich zunächst meine Annahmen formulieren:

  1. Jede Seite kann beliebige Daten senden
  2. Daten werden in 8-N-1-Form gesendet (8 Datenbits, keine Parität, 1 Stoppbit)
  3. Sie können jedes Ende so einrichten, dass es kontinuierlich sendet

Sehen wir uns an, wie serielle Daten normalerweise gesendet werden. Schauen wir uns die Bytes an, 0x55, 0x55wie sie auf einer Single-Ended-Datenverbindung (RS-232) gesendet werden könnten.

+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   +---
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   
+---+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   +---+   
  S   1   0   1   0   1   0   1   0   P   S   1   0   1   0   1   0   1   0   P 

In diesem Diagramm Sist ein Startbit und Pein Stoppbit und die 8 Datenbits werden wie üblich mit dem niederwertigsten Bit zuerst gesendet. Aus dieser Betrachtung sollte klar sein, dass, wenn Sie die Frequenz dieser Wellenform messen, sie genau die Hälfte der Bitrate sein sollte.

Am Ende der Nachricht befindet sich eine Prüfsumme, aber da ich den Header nicht richtig bekomme, vertraue ich den restlichen Daten, einschließlich des Werts der Prüfsumme, nicht besonders. Ich habe das Gefühl, dass es viel eher an der Taktrate liegt. Früher funktionierte es mit einer Baudrate von 115.200 , aber ich musste das ändern. 2,27 us ist in der Tat ziemlich kurz. Wie würde ich vorgehen, um dies zu überprüfen?

Welche Taktrate verwendest du?

Bei einem 8 MHz Takt finde ich keinen akzeptablen Prescaler Wert für 460800 Baud. 14,7456 MHz könnten ausreichen ("WormFood's AVR Baud Rate Calculator").