Diskussion:Universal Asynchronous Receiver Transmitter

Artikelqualität

Naja, wirklich schlauer bin ich jetzt leider auch nicht... Wo wird so etwas denn eingesetzt? Warum? ...
(nicht signierter Beitrag von 84.130.173.195 (Diskussion) 09:27, 10. Okt. 2005 (CEST)) --JoBa2282 ^{Red mit mir} 14:23, 17. Dez. 2008 (CET)

USART (Universal Synchronous Asynchronous Receiver Transmitter) ist eine Gruppe von UART und wird z.B. bei der SPI (Serial Peripheral Interface) von MCUs eingesetzt. Mit SPI kann man z.B. Daten in einen Speicher schreiben; ADCs auslesen oder einen CAN Controller steuern.
(nicht signierter Beitrag von Volkerhofacker (Diskussion | Beiträge) 15:58, 20. Mär. 2006 (CET)) --JoBa2282 ^{Red mit mir} 14:23, 17. Dez. 2008 (CET)

In gewisser Weise kann ich deine Frage verstehen: der Artikel ist mehr als dürftig. Da ein UART heute praktisch nicht mehr an PCs verwendet wird, sinkt seine Bedeutung sehr stark ab. Allerdings basierte vor 20..25 Jahren die gesamte Modem-Kommunikation auf UARTs, selbst Per-to-peer Verbindungen mit Computern wurden so realisiert, weil nur ein dreipoliges, leicht selbst zu bauendes Kabel benutzt werden konnte. Man benutzt UARTs gelegentlich noch im sogenannten Embedded Market, der im industriellen Sektor eine große Rolle spielt. Mit USB 2.0, steigender Verfügbarkeit von USB-Microcontrollern und passenden Preisen werden UARTs wohl bald nur noch als Unterblock eines ASIC/FPGA zu finden sein. Aber schau doch mal für eine weitergehende Beschreibung unter EIA-232. --Peter Bensch 09:14, 9. Jun 2006 (CEST)

Das S in USART steht für serial. Synchron und asynchron zugleich, würde auch keinen Sinn machen. Die Abkürzung steht also für: Universal Serial Asynchronous Receiver Transmitter. USART und UART sind meines Wissens nach zwei Namen für ein und die selbe Sache. MCU's haben oft diesen Port; er ist identisch mit dem seriellen Port an PCs (kann über Nullmodem verbunden werden). Siehe auch RS232. Unheil 13:07, 15. Feb. 2007 (CET)

Ich denke, dass USART Universal Synchronous and Asynchronous Receiver Transmitter heisst, da diese Schnittstelle sowohl asynchron, mit minimal zwei Leitungen (Transmit, Receive) als auch synchron (Clock Leitung kommt noch dazu) genutzt werden kann. Je nach Einstellung im Control Register. Einwandfreie Quellen habe ich aber auch nicht. Auf Seiten die ich bis jetzt zu dem Thema besucht habe las ich "Synchronous and Asynchronous", das waren nicht sehr viele und auch die mögen sich geirrt haben. In deiner Bezeichnung taucht aber "Synchron" gar nicht mehr auf, obwohl die Übertragung ja durch die Clock-Leitung synchronisiert werden kann. -- Sebastian 12:30, 04. Feb 2008
(nicht signierter Beitrag von 217.64.173.97 (Diskussion) 12:29, 4. Feb. 2008 (CET)) --JoBa2282 ^{Red mit mir} 14:23, 17. Dez. 2008 (CET)

Begrenzung Datenbits: Woher?

[...]fünf bis maximal neun Datenbits[...] woher kommt diese Grenze. Ist ein UART nicht eine allgemeine Bezeichnung? Kann es nicht auch UARTs geben mit mehr Datenbits? Z. B. bei AS-Interface
(nicht signierter Beitrag von 90.187.128.87 (Diskussion) 21:22, 25. Nov. 2007 (CET)) --JoBa2282 ^{Red mit mir} 14:23, 17. Dez. 2008 (CET)

Antwort jetzt im Artikel. Gruß --JoBa2282 ^{Red mit mir} 14:28, 17. Dez. 2008 (CET)

Stopp-Bits

"zur Erkennung von Übertragungsfehlern und einem oder mehreren (auch 1,5 Bit kommen vor) Stopp-Bits besteht"

Also mit dieser Formulierung bin ich gar nicht einverstanden. Es gibt nur 1 Stopp-Bit. Allerdings kann er Zeitintervall, die dieses Stopp-Bit ansteht, auf 1,5 bzw. 2 "Bit-Zeiten" verlängert werden kann. Eine "Bit-Zeit" ist die Zeit, die die Übertragung eines Bits (enstprechend seinem logischen Pegel 0 oder 1) dauert. Das ist von der Übertragungsrate abhängig. Die Abfrage eines Bits erfolgt immer zur Mitte dieser Übertragungszeit, damit kleine Sync-Fehler keinen Lesefehler verursachen (Fallende/Steigende Flanke). Die Stopp-Bit-Zeit wird deswegen verlängert, um dem Empfänger eine gewisse Verarbeitungszeit der empfangenen Daten einzuräumen.

Gruß --JoBa2282 ^{Red mit mir} 09:25, 19. Dez. 2008 (CET)

Habe den Text schonmal etwas angepasst. Gruß --JoBa2282 ^{Red mit mir} 09:34, 19. Dez. 2008 (CET)

Also in den Datenblättern der einschlägigen Chips findet man tyischerweise Statusbits im Konfigurationsregister, wo man "Anzahl der Stoppbits" einstellen kann, und da gibt es typischerweise die Alternativen 0, 1, 1,5 und 2. Wenn die das so nennen, können wir das doch auch? Und auch wenn Du es etwas anders formulierst, der Sachverhalt ist doch derselbe. Und wieso soll man um den heißen Brei herumreden und sich bei Angaben >1 so zieren und da so rumschwurbeln? Finde ich unnötig. Wer soll denn mal festgelegt haben, dass es nur 1 Stoppbit gibt? Ich kenne das von Anfang an anders. --PeterFrankfurt 00:52, 20. Dez. 2008 (CET)

wenn ich mich mal wegen der Stopp-Bits einschalten darf: wozu braucht man die? bei asynchroner Datenübertragung haben Sender und Empfänger unterschiedliche Takte, einer von beiden darf schneller laufen als der andere. Deswegen macht der Empfänger (=Chip) eine Synchronisation auf die ankommende Signalfolge, und zwar für jedes Codewort (=Byte) neu. Erstens arbeitet er mit der eingestellten Geschwindigkeit und dem daraus resultierenden eigenen Takt. Der kann aber wegen der Asynchronität ungenau sein. Deswegen leitet er sich zweitens seinen Empfangstakt aus dem ankommenden Signal ab. Er arbeitet also mit zwei Taktsignalen. Er tastet das ankommende Signal mit (meistens) sechzehnfacher Geschwindigkeit ab, wozu er den eigenen Takt benutzt. Hat er dann das Startbit erkannt, startet er den Byte-Empfangstakt. Das ist der zweite Takt, mit dem er arbeitet. Er synchronisiert sich nicht auf die Bits, sondern auf die Bytes. Diese Schaltung für den Byte-Empfangstakt braucht eine gewisse Zeit, um nach dem Empfang eines Bytes anzuhalten, sich auf Null zu setzen und den Synchronisationszyklus wieder neu zu starten. Die Übertragungsleitung muß in dieser Zeit im Ruhezustand sein. Diese Ruhezeit hat eine gewisse Dauer. Man spricht dann von 1, 1,5 oder 2 Stopp-Bits, je nach Dauer. 89.48.0.172 01:38, 20. Dez. 2008 (CET)

Habe etwas am Text gefeilt, dass er nun genauer ist, weiß ich. Ob er für Laien auch klarer ist, kann ich nicht so beurteilen. 89.48.0.172 02:06, 20. Dez. 2008 (CET)

Hmm, also ich kenne die Innereien der Chips nicht, aber ich war immer davon ausgegangen, dass die sich einen Bittakt machen (den sie per Startbitflanke auf den Sendetakt synchronisieren) und nicht einen Bytetakt. Und die Stoppbits sind vor allem da, dem Empfänger Zeit zu geben, das Byte abzulegen und sonstige Overhead-Geschichten zu erledigen (Parity-Prüfung), früher machte das ja auch die CPU selbst zu Fuß, und da konnte das ganz schön dauern, da musste man sich auch bei 2 Stoppbits schon gut sputen. --PeterFrankfurt 02:20, 20. Dez. 2008 (CET)

Ist schon richtig, was Du sagst. Aber nochmal zum Takt: Den Bittakt müssen die Empfängerchips nicht machen, dazu nehmen sie den eigenen Chip-Takt, den sie je nach Einstellung runterteilen. Aber dann wissen sie noch nicht, wo der Übertragungsrahmen anfängt. Den Rahmenanfang kriegen sie damit hin, dass sie sagen, 16-mal die Eins auf der Empfangsleitung ausgetastet, das muß es sein, hier fängt der Rahmen an. (eine einzige Flanke wäre viel zu fehlerbehaftet, das machen nur Chips untereinander so). Jetzt könnte der Empfänger ja sagen, alles klar, ich habe meinen eingestellten Takt und den ersten Rahmenanfang, den zweiten Rahmenanfang rechne ich mir aus. Bis zum nächsten Rahmenanfang sind es ja nur x Taktzyklen, bis zum übernächsten 2x Taktzyklen, usw. Das kann aber in die Hose gehen. 16-mal die Eins, das ist genau zwischen 15 und 17, also eine Ungenauigkeit von ca. 7% ist drin. Wenn der Empfänger also den Sendertakt nur mit 7% Genauigkeit bestimmt hat, kann er nach sagen wir mal 20 Rahmen schon wieder voll daneben liegen. Deswegen kann der Empfänger so nicht arbeiten. Er muß sich ständig neu auf jeden Rahmenanfang synchonisieren. Das ist dann der sogenannte Bytetakt. Den Bytetakt kann der Uart dann auch hernehmen, um dem Prozessor zu sagen, komm abholen, ein Byte ist angekommen.89.48.0.172 02:44, 20. Dez. 2008 (CET)

Also das geht m. E. anders. In der Tat kann sich der Empfänger nicht auf einen konstanten Abstand der Rahmen verlassen. Deshalb muss er sich für jedes neue Byte (jeden neuen Rahmen) auf dessen Anfangsflanke neu synchronisieren. D. h. die Stoppbits geben nur das Minimum für den Zeitabstand zwischen zwei Rahmen an, im Endeffekt wird der Abstand eher etwas länger sein. Und natürlich wird nicht nur einfach die erste Flanke des Startbits genommen, es könnte sich ja auch um einen Störimpuls handeln, sondern der Chip wird die letzten 16 Samples nehmen und eine Mehrheitsentscheidung daraus bilden. Bei verrauschtem Eingang braucht es da wahrscheinlich hochintelligente Ansätze, den wahren Bitanfang herauszudetektieren. Die Stoppbits werden natürlich nicht aktiv gelesen. Nach den (z. B.) acht Datenbits kennt der Chip den Eingangswert und löst einen Interrupt aus, damit der Prozessor das Byte abholen kann, da sehe ich keinen Takt im Sinne eines Bytetaktes, nur die abgelaufene Zeit eines Byterahmens, der sich aus n+1 (1 wegen Startbit) Bitlängen ergibt. --PeterFrankfurt 23:17, 20. Dez. 2008 (CET)

Im Großen und Ganzen hast du begriffen, dass Start- und Stopp-Bits Hilfsmittel sind, um Synchronisationsprobleme zu lösen, die dann entstehen, wenn Sender und Empfänger keinen gemeinsamen Takt haben. Byte-orientierte asynchrone Kommunikation muß sich ständig neu auf die ankommenden Datenbytes synchronisieren. Das wollte ich rüberbringen und das ist wohl auch angekommen. Wie oft nun eine "1" registriert worden sein muß, dass ein Bit auf der Leitung gültig ist, das ist die spezifische Realisierung des IC. Unabhängig davon, ob es sich um ein Startbit, Stoppbit oder Datenbit handelt. "16-Takte-lang hoher Pegel" ist nur ein typisches Verfahren. Wie die Prozessorkommunikation des UART dann aussieht, ist ein zweiter Aspekt. UARTs haben längst interne Speicherbereiche, in die 2 oder sogar viele Bytes passen, damit der Prozessor nicht sofort reagieren muß, um das empfangene Byte abzuholen, bevor der UART das erste Bit des nächsten empfangenen Bytes abspeichern muß. 89.48.21.140 00:55, 21. Dez. 2008 (CET)

Mir kommt da spontan so ein Gedanke, wie man eine Schnittstelle mit leicht abgewandeltem UART-Prinzip dauerhaft über viele Bytes hinweg synchronisieren könnte: Dazu hätte das Stopp-Bit nur die Länge (Dauer) 1 und wäre nicht immer 1 bzw. HI, sondern das invertierte vorherige Bit (also einfach ein Umschalten von HI auf LO bzw. von LO auf HI). So hätte man an dieser Stelle (nach dem letzten Bit eines Bytes) immer eine Schaltflanke an der man nach jedem Byte neu synchronisieren kann. Sogar das Startbit könnte so ab dem zweiten Byte wegfallen, weil das Stopbit ja nun die Synchronisation übernimmt und damit gleichzeitig als Startbit dienen kann. Ein Ende der Übertragung könnte man dadurch kennzeichnen, dass nach dem letzten übertragenen Byte das Stopbit (also der Flankenwechsel) entfällt, bzw. erst eine Bit-Dauer später ggf. auf HI geschaltet wird. So kann frühestens schon eine weitere Bit-Dauer später Ein nächstes Startbit (LO) für die nächste Übertragung gesendet werden.

Wer's nun zum Patent anmeldet, kann mir ja ein paar Euro abgeben.  ;-) --R.sont (Diskussion) 15:06, 24. Nov. 2024 (CET)

Das Heute fehlt völlig: CMOS-UART

RS232 ist aufgrund der elektrischen Unmöglichkeiten (nicht differenziell/ Erdschleifenprobleme) ein Auslaufmodell. Aber jeder kleine, moderne Mikrocontroller (8 Bit bis 32 Bit) hat heute eine oder mehrere UART(s) eingebaut (sog. CMOS-UART). Einer der kleinsten mit einer Duplex-UART (Rx/Tx) ist zum Beispiel der Atmel ATtiny2313. Über einen USB/VCP Device-Controller (FT232, CP210x o.ä.) kommuniziert man dann direkt mit dem Hyperterminal eines WindowsXP-Rechners via ASCII-Alphabet. Meist benutzt man das einfachste, was machbar ist: 8-1-n-n (8 Bit, 1 Stopbit, keine Parität, keine Flußkontrolle) sowie Datenraten zwischen 9600 ... 115200 ... 921600 Bit/s. Es existieren nur zwei Leitungen: Tx (transmit) und Rx (receive). Bei der Programmierung erhält oder gibt das UART Rx/Tx-Datenregister des Prozessors nur einen 8 Bit Wert (1 Byte) - fertig. Hier ist die Gegenwart der UARTs aktuell - und wird es noch lange bleiben. Praktisch gibt es keine einfachere und preiswertere Schnittstelle für den Datenaustausch, auch wenn SPI und TWI in der Nähe liegen. Jede der drei Schnittstellen hat ganz spezielle Vorzüge. So gestattet SPI lange Schiebeketten bei adreßfreien Modulen, TWI hingegen gestattet soft-adressierte Kommunikation (ohne Nummer geht gar nichts).

Grundlagen findet man zum Beispiel unter [mikrocontroller.net].

• Programmierung einer [UART]
• UART-Schnittstelle an [USB-Controller]
• Beispiel einer Kommunikation: [Hyperterminal-USB/VCP-UART-ATmega8]

So gesehen ist der Beitrag nicht mehr ganz zeitgemäß.

--Heinzelmann 13:39, 13. Jul. 2010 (CEST)

Also ich sehe nicht, was an einem CMOS-UART anders ist als an einem PMOS- oder NMOS-UART von (sehr) kurz davor. Den Begriff gibt es in der Form meinem Eindruck nach auch gar nicht, das CMOS steht da ganz allgemein zur Kennzeichnung der Bauart dabei, hat aber zur Funktionalität rein gar nichts zu sagen. Dass heutige UARTs noch ein bisschen mehr können als die vor 20 Jahren, ist ja wohl ein Allgemeinplatz. Vor allem die oben erwähnte Zwei- (eigentlich drei mit Masse)-Leitungs-Technik gab es aber schon immer bei UARTs (Soft-Handshake X-On/X-Off), auch die Byte-parallele Anbindung an den Prozessor war schon immer ein Merkmal eines UARTs. Insofern hast Du mich noch nicht überzeugt, dass da was Prinzipielles im Artikel fehlt. --PeterFrankfurt 01:35, 14. Jul. 2010 (CEST)

Eine Datenleitung?

Über eine Datenleitung Senden und Empfangen TX RX !? --79.254.126.22 16:33, 31. Mär. 2013 (CEST)