Gibt es einen Standard, der das UART-Datenrahmenprotokoll beschreibt?

Das "U" in "UART" steht für "Universal", aber ich habe Probleme, einen Standard zu finden, der das in UART verwendete Framing-Protokoll beschreibt. B. Startbit, Stoppbit, Paritätsoptionen und Baudraten, die Sie in seriellen Kommunikationsclients wie Minicom oder Putty sehen.

Ich verstehe, dass es an dieser Stelle bekannte Konventionen dafür gibt, wie diese Dinge gemacht werden, aber Standards wie RS-232/RS-422/D-Subminiatur scheinen nichts über die physikalische Signalisierung hinaus zu beschreiben oder vorzuschlagen.

Ich hatte auch Probleme, eine Spezifikation für die Zuordnung der seriellen Signalisierung auf die Pinbelegung eines DE9-Anschlusses zu finden, mit der UART-Hardware verschiedener Anbieter effektiv über eine gemeinsame Pinbelegung (wie einen "Nullmodem" -Anschluss) kommunizieren kann.

Wird das alles durch Konvention erreicht (z. B. durch die historische Dominanz einiger Bits einer seriellen Hardware auf dem Markt wie 16*50s), oder übersehe ich da draußen einige Standards? TIA für die Einblicke!

In einem Kommentar zu meinem Beitrag ( electronics.stackexchange.com/questions/389574/… ) sagt Jason, dass es offiziell „Asynchronous NRZ code“ heißt.

Antworten (1)

Wikipedia hat eine ziemlich anständige Beschreibung, wie die verschiedenen Dinge wie Startbits, Stoppbits und Paritätsbits funktionieren. Sie können es hier finden . Es beschreibt nicht wirklich die Baudrate. Das ist nur die Anzahl der Bits pro Sekunde, die übertragen werden, einschließlich aller Startbits, Stoppbits und Paritätsbits. Als grobe Faustregel können Sie davon ausgehen, dass etwa 10 Bit benötigt werden, um ein Byte zu senden.

Was die Zuordnung der seriellen Leitungen zu den Pins eines DE9-Steckers betrifft, kann dies zunächst etwas verwirrend sein. Wenn zwei Geräte über RS232 und ein Straight-Through-Kabel verbunden sind, ist eine Seite das Data Terminal Equipment (DTE) und eine Seite das Data Communications Equipment (DCE). Egal welche Seite welche ist, die Pins am Kabel werden immer aus Sicht der DTE benannt. Das führt zu der verwirrenden Situation, in der das DCE auf der Empfangsleitung sendet (weil das DTE dieses Signal empfängt) und auf der Sendeleitung empfängt (weil dort das DTE sendet). Die meisten Menschen wollen eher die DTE sein, damit sie nicht alles in ihren Köpfen umkehren müssen. Wenn Sie zwei Endgeräte haben, die miteinander sprechen möchten, benötigen Sie ein Nullmodemkabel.

Die Pins auf einem DE9-Stecker sind wie folgt:

  • Pin 1 - Datenträgererkennung (DCD)
  • Pin 2 - Daten empfangen (RD)
  • Pin 3 - Daten übertragen (TD)
  • Pin 4 - Datenterminal bereit (DTR)
  • Pin 5 - Masse
  • Pin 6 - Datensatz bereit (DSR)
  • Pin 7 - Sendeanforderung (RTS)
  • Stift 8 – Sendebereit (CTS)
  • Pin 9 - Ringanzeige (RI)

Die meisten dieser Pins sind aus Legacy-Gründen vorhanden und es ist unwahrscheinlich, dass Sie sie benötigen werden. Die drei, die Sie benötigen, sind Daten übertragen (Pin 3), Daten empfangen (Pin 2) und Masse (Pin 5). Wenn Sie diese Signale wirklich an einen DE9-Anschluss anschließen, werden Transmit Data und Receive Data mit den entsprechenden RS232-Signalpegel-Pins auf Ihrem RS232-Transceiver-Chip (wie einem MAX232) verbunden, und die Logikpegelseite Ihres RS232-Chips wird mit Ihnen verbunden UART. Der Erdungsstift wird mit dem Erdungsstift des RS232-Transceiver-Chips und mit dem Erdungsstift des UART verbunden. Eine Sache, die Sie beachten sollten, wenn Sie beginnen, die Signale am DE9-Anschluss mit einem Messgerät oder einem Oszilloskop zu untersuchen, ist, dass der RS232-Transceiver alle Signale invertiert und pegelversetzt. Was am UART ein 0-Volt-Logik-Low-Signal war, wird am DE9-Anschluss zu einer positiven Spannung zwischen 5 und 15 Volt. Was am UART ein logisch hohes Signal war, wird am DE9-Anschluss zu einer negativen Spannung zwischen -5 und -15 Volt.

Wenn Sie nicht wirklich durch einen DE9-Anschluss gehen, sondern wirklich nur zwei UARTs auf derselben Platine miteinander verbinden, können Sie die RS232-Transceiver-Chips überspringen. Ein Beispiel dafür, wo Sie darauf stoßen könnten, ist eine Anwendung, bei der Sie einen Mikroprozessor mit einem handelsüblichen Funkmodul verbinden, das eine UART-Schnittstelle verwendet.

Wie ich bereits sagte, ist es unwahrscheinlich, dass Sie die anderen Stifte benötigen. Sie wurden hauptsächlich benötigt, wenn die Fernkommunikation über DFÜ-Telefonmodems durchgeführt wurde. Wenn Sie eine Anwendung haben, die besagt, dass sie Hardware-Flusskontrolle verwendet, werden einige oder alle dieser Pins benötigt. Hier ist, wofür sie sind:

  • DCD ist ein Signal vom Telefonmodem (DCE) an das DTE, dass es ein Trägersignal vom Modem am fernen Ende erkennt. Es bedeutet im Grunde, dass Sie eine Verbindung haben.
  • DTR ist ein Signal vom DTE zum DCE, das besagt, dass es eingeschaltet und einsatzbereit ist.
  • DSR ist ein Signal vom DCE zum DTE, das besagt, dass es eingeschaltet und einsatzbereit ist.
  • RTS ist ein Signal von der DTE an die DCE, das besagt, dass es Daten senden möchte.
  • CTS ist ein Signal von der DCE an die DTE, das besagt, dass es bereit ist, Daten zu empfangen.

RTS und CTS sind die am häufigsten verwendeten Pins für die Hardware-Flusskontrolle. Wenn Sie zwei DTE-Geräte haben, die über ein Nullmodemkabel miteinander verbunden werden und Hardware-Flusskontrolle verwenden möchten, muss das Kabel RTS auf der einen Seite mit CTS auf der anderen Seite verbinden und umgekehrt. Diese Signale würden dann durch die RS232-Signalpegelseite Ihres RS232-Transceiver-Chips laufen und die Logikseite würde sich mit Allzweck-IO-Pins auf Ihrem Mikroprozessor verbinden, die den RTS-Pin bestätigen würden, wenn er kommunizieren wollte, und die den CTS-Pin überwachen würden, um zu sehen wenn die andere Seite der Kommunikationsverbindung kommunikationsbereit war.

Die Alternativen zur Verwendung der Hardware-Flusskontrolle sind:

  • Seien Sie immer bereit zu kommunizieren.
  • Haben Sie eine Anwendung, die sich leicht von verpassten Kommunikationen erholen kann.
  • Verwenden Sie die Software-Flusskontrolle. Dies beinhaltet die Verwendung von Sonderzeichen (wie das ASCII-Zeichen XON (Senden an) und das ASCII-Zeichen XOFF (Senden aus) zum Drosseln der Übertragungen.

Die Flusskontrolle, ob Hardware oder Software, wird von Ihrem UART nicht selbst gehandhabt. Sie müssen eine Software in Ihrer Anwendung haben, die dies bei Bedarf handhabt. Viele Anwendungen verwenden überhaupt keine Low-Level-Flusskontrolle. Sie laufen schnell genug, um die langsame Kommunikation zu bewältigen, die über UARTs erfolgt, ohne die Flusskontrolle zu verwenden, um auf niedrigem Niveau zu drosseln. Auf der höheren Ebene (wie „Bin ich wirklich mit dem Gerät am anderen Ende verbunden?“) verwenden sie Software auf höherer Ebene. Ein Beispiel hierfür wäre ein leistungsschwacher Prozessor, der über eine serielle Verbindung mit einem Modul kommuniziert, das eine Ethernet-Verbindung aufbaut. In diesem Fall ist die allgemeine Frage "Bin ich verbunden?" würde mit Dingen wie TCP/IP gehandhabt werden.