AVR-Tutorial: UART
Wie viele andere Controller besitzen die meisten AVRs einen UART (Universal Asynchronous Receiver and Transmitter). Das ist eine serielle Schnittstelle, die meistens zur Datenübertragung zwischen Mikrocontroller und PC genutzt wird. Dafür werden zwei Pins am Controller benötigt: TXD und RXD. Über TXD (Transmit Data) werden Daten gesendet, RXD (Receive Data) dient zum Empfang von Daten.
Hardware
Um den UART des Mikrocontrollers zu verwenden, muss der Versuchsaufbau um folgende Bauteile erweitert werden:
Auf vielen Evaluation-Boards sind diese Bauteile bereits enthalten, man muss ggf. nur noch die Verbindungen zwischen MAX232 und AVR herstellen.
- Der MAX232 ist ein Pegelwandler, der die −12/+12-Volt-Signale an der seriellen Schnittstelle des PCs zu den 5/0 Volt des AVRs kompatibel macht.
- C1 ist ein kleiner Elektrolyt-, Tantal- oder Keramikkondensator, wie er immer wieder zur Entkopplung der Versorgungsspannungen an digitalen ICs verwendet wird.
- Die vier Kondensatoren C2…C5 sind Elektrolyt-, Tantal- oder Keramikkondensatoren (siehe Datenblatt der verwendeten MAX232-Version!). Falls Elkos oder Tantals verwendet werden, auf die richtige Polung achten! Der exakte Wert ist hier relativ unkritisch, in der Praxis sollte alles von ca. 1 µF bis 47 µF mit einer Spannungsfestigkeit von 16 V und höher funktionieren.
- X1 ist ein weiblicher 9-poliger SUB-D-Verbinder.
- Die Verbindung zwischen PC und Mikrocontroller erfolgt über ein 9-poliges Modem-Kabel (also ein Verlängerungskabel, kein Nullmodem-Kabel!), das an den seriellen Port des PCs angeschlossen wird. Bei einem Modem-Kabel sind die Pins 2 und 3 des einen Kabelendes mit den Pins 2 und 3 des anderen Kabelendes durchverbunden. Bei einem Nullmodem-Kabel sind die Leitungen gekreuzt, sodass Pin 2 von der einen Seite mit Pin 3 auf der anderen Seite verbunden ist und umgekehrt.
- Als Faustregel kann man annehmen: Befinden sich an den beiden Enden des Kabels die gleiche Art von Anschlüssen (Männchen = Stecker; Weibchen = Buchse), dann benötigt man ein gekreuztes, also ein Nullmodem-Kabel. Am PC-Anschluss selbst befindet sich ein Stecker, also ein Männchen, sodaß am Kabel auf dieser Seite eine Buchse (also ein Weibchen) sitzen muss. Da am AVR laut obigem Schaltbild eine Buchse verbaut wird, muss daher an diesem Ende des Kabels ein Stecker sitzen. Das Kabel hat somit an einem Ende einen Stecker und am anderen Ende eine Buchse und ist also ein normales Modem-Kabel (= nicht gekreuzt).
Software
UART konfigurieren
Als erstes muss die gewünschte Baudrate im Register UBRR festgelegt werden. Der in dieses Register zu schreibende Wert errechnet sich nach der folgenden Formel:
[math]\displaystyle{ \text{UBRR} = \frac{\text{Taktfrequenz (in Hz)}} { 16 \cdot \text{Baudrate} } - 1 }[/math]
Beim AT90S4433 kann man den Wert direkt in das Register UBRR laden, beim ATmega8 gibt es für UBRR zwei Register: UBRRL (Low-Byte) und UBRRH (High-Byte). Bei Baudraten über etwa 3.900 Bit/s (gilt nur bei Verwendung eines Takts von 16 MHz) steht in UBRRH eine 0, da der berechnete Wert kleiner als 256 ist und somit in UBRRL alleine passt. Beachtet werden muss, dass das Register UBRRH vor dem Register UBRRL beschrieben werden muss. Der Schreibzugriff auf UBRRL löst das Neusetzen des internen Taktteilers aus.
Wichtiger Hinweis 1
Es empfiehlt sich, statt der oben genannten Formel die Formel der Codebeispiele zu verwenden:
[math]\displaystyle{ \text{UBRR} = \frac{\text{Taktfrequenz (in Hz)} + (\text{Baudrate} \cdot 8)}{(\text{Baudrate} \cdot 16)}-1 \quad \left( = \frac{ \text{Taktfrequenz (in Hz)} }{ 16 \cdot \text{Baudrate} } -0.5 \right) }[/math]
Beispiel: Bei einem ATMega mit 16 MHz und 115200 Baud ist der Wert laut Datenblatt UBBRL=8. Rechnet man mit der Formel UBRRL=(F_CPU / (UART_BAUDRATE* 16L) - 1), ergibt sich ein Wert von 7,680555 und im UBRRL-Register steht somit eine 7 statt einer 8. Die Verwendung der Formel aus dem Codebeispiel ergibt 8,180555 und im UBRRL-Register steht somit der richtige Wert – nämlich 8.
Wichtiger Hinweis 2
Aufgrund permanent wiederkehrender Nachfrage sei hier ausdrücklich darauf hingewiesen, dass bei Verwendung des UART im asynchronen Modus dringend ein Quarz oder Quarzoszillator verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt, dass eine UART-Schaltung, die im Winter noch funktionierte, im Sommer den Dienst verweigert.
Außerdem muss bei der Berechnung von UBRR geprüft werden, ob mit der verwendeten Taktfrequenz die gewünschte Baudrate mit einem Fehler von <1 % generiert werden kann. Das Datenblatt bietet hier sowohl die Formel als auch Tabellen unter der Überschrift des U(S)ART an.
[math]\displaystyle{ \frac{\text{Fehler}_{\text{Baudrate}}}{\text{%}} = \left( \frac{\text{UBRR}_{\text{gerundet}}+1}{\text{UBRR}_{\text{genau}}+1} -1 \right) \cdot 100 }[/math]
Siehe auch Baudratenquarz.
Wer es ganz einfach haben will, nimmt die folgenden Macros. Die rechnen sogar den Fehler aus und brechen die Assemblierung ggf. ab. Das ist dann praktisch idiotensicher.
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
Wer dennoch den internen RC-Oszillator verwenden will, muss diesen kalibrieren. Näheres findet man dazu im Datenblatt, Stichwort Register OSCCAL.
Um den Sendekanal des UART zu aktivieren, muss das Bit TXEN im UART-Control-Register UCSRB auf 1 gesetzt werden.
Danach kann das zu sendende Byte in das Register UDR eingeschrieben werden – vorher muss jedoch sichergestellt werden, dass das Register leer ist, die vorhergehende Übertragung also schon abgeschlossen wurde. Dazu wird getestet, ob das Bit UDRE (UART Data Register Empty) im Register UCSRA gleich 1 ist.
Genaueres über die UART-Register findet man im Datenblatt des Controllers.
An dieser Stelle sei noch folgendes angemerkt: Das UDRE-Bit sagt nichts darüber aus, ob der Controller immer noch damit beschäftigt ist, Daten zu senden. Da das Senderegister mehrfach gepuffert ist, wird UDRE bereits gesetzt, obwohl das letzte Zeichen den AVR noch nicht komplett verlassen hat. Dies kann insbesondere bei der Verwendung von Sleep-Modes ein Problem werden, wenn der Controller schlafen gelegt wird, bevor das letzte Zeichen versendet wurde, da dies gezwungenermaßen zu einem Frame-Error beim Empfänger führen wird. Um sicher zu gehen, dass der UART nicht mehr beschäftigt ist, kann das Bit TXC (UART Transmit Complete) getestet werden. Dieses wird jedoch wirklich erst nach dem Senden eines Zeichens gesetzt, beinhaltet also auch nach dem Systemstart eine 0, obwohl der Controller nichts sendet.
Der ATmega8 bietet noch viele weitere Optionen zur Konfiguration des UARTs, aber für die Datenübertragung zum PC sind im Normalfall keine anderen Einstellungen notwendig.
Senden von Zeichen
Das Beispielprogramm überträgt die Zeichenkette „Test!“ in einer Endlosschleife an den PC.
Hinweis: Wenn man das nachfolgende Programm laufen lässt und Hyperterminal startet, scheint es problemlos zu funktionieren. Wenn man aber das RS232-Kabel zwischenzeitlich abzieht und wieder ansteckt, wird es oft passieren, dass nur noch wirre Zeichen auf dem PC erscheinen. Das liegt daran, dass der PC aus einem ununterbrochenen Zeichenstrom nicht den Anfang eines Zeichens erkennen kann. Darum muss in solchen Fällen periodisch eine kleine Pause von der Länge mindestens eines Zeichens eingelegt werden, damit der PC sich wieder synchronisieren kann.
Die folgenden Beispiele sind für den ATmega8 geschrieben.
.include "m8def.inc"
.def temp = r16 ; Register für kleinere Arbeiten
.def zeichen = r17 ; In diesem Register wird das Zeichen an die
; Ausgabefunktion übergeben.
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp
; Baudrate einstellen
ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp
; Frame-Format: 8 Bit
ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp
sbi UCSRB, TXEN ; TX aktivieren
loop:
ldi zeichen, 'T'
rcall serout ; Unterprogramm aufrufen
ldi zeichen, 'e'
rcall serout ; Unterprogramm aufrufen
ldi zeichen, 's'
rcall serout ; ...
ldi zeichen, 't'
rcall serout
ldi zeichen, '!'
rcall serout
ldi zeichen, 10
rcall serout
ldi zeichen, 13
rcall serout
rcall sync
rjmp loop
serout:
sbis UCSRA, UDRE ; Warten bis UDR für das nächste
; Byte bereit ist
rjmp serout
out UDR, zeichen
ret ; zurück zum Hauptprogramm
; kleine Pause zum Synchronisieren des Empfängers, falls zwischenzeitlich
; das Kabel getrennt wurde
sync:
ldi r16, 0
sync_1:
ldi r17, 0
sync_loop:
dec r17
brne sync_loop
dec r16
brne sync_1
ret
Der Befehl rcall serout ruft ein kleines Unterprogramm auf, das zuerst wartet, bis das Datenregister UDR von der vorhergehenden Übertragung frei ist, und anschließend das in zeichen (= r17) gespeicherte Byte an UDR ausgibt.
Bevor serout aufgerufen wird, wird zeichen jedesmal mit dem ASCII-Code des zu übertragenden Zeichens geladen (so wie in Teil 4 bei der LCD-Ansteuerung). Der Assembler wandelt Zeichen in einfachen Anführungsstrichen automatisch in den entsprechenden ASCII-Wert um. Nach dem Wort „Test!“ werden noch die Codes 10 (Line Feed oder New Line, Zeilenvorschub) und 13 (Carriage Return, Wagenrücklauf) gesendet, um dem Terminalprogramm mitzuteilen, dass eine neue Zeile beginnt.
Eine Übersicht aller ASCII-Codes gibt es auf 4n7.de/ascii.html oder Wikipedia.
Die Berechnung der Baudrate erfolgt übrigens nicht im Controller während der Programmausführung, sondern schon beim Assemblieren, wie man beim Betrachten der Listingdatei feststellen kann.
Zum Empfang muss auf dem PC ein Terminal-Programm wie z. B. PuTTY gestartet werden. Der nebenstehende Screenshot zeigt, welche Einstellungen im Programm vorgenommen werden müssen.
Linux-Benutzer können das entsprechende Device (z. B. /dev/ttyS0) mit stty konfigurieren und mit cat die empfangenen Daten anzeigen oder ein Terminalprogramm wie minicom nutzen.
Alternativ kann unter Windows und Linux HTerm genutzt werden (Freeware).
Senden von Zeichenketten
Eine bequemere Methode, um längere Zeichenketten (Strings) zu übertragen, ist hier zu sehen. Dabei werden die Zeichenketten im Flash gespeichert. Als Abschluss des Strings wird der Wert 0x00 genutzt, so wie auch in der Programmiersprache C.
.include "m8def.inc"
.def temp = r16 ; Register für kleinere Arbeiten
.def zeichen = r17 ; In diesem Register wird das Zeichen an die
; Ausgabefunktion übergeben.
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
; hier geht unser Programm los
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp
; Baudrate einstellen
ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp
; Frame-Format: 8 Bit
ldi temp, (1<<URSEL)|(3<<UCSZ0)
out UCSRC, temp
sbi UCSRB, TXEN ; TX aktivieren
loop:
ldi zl, low(my_string*2); ; Z Pointer laden
ldi zh, high(my_string*2);
rcall serout_string
rjmp loop
; Ausgabe eines Strings aus dem Flash
serout_string:
lpm ; nächstes Byte aus dem Flash laden
and r0, r0 ; = Null?
breq serout_string_ende ; wenn ja, -> Ende
serout_string_wait:
sbis UCSRA, UDRE ; Warten, bis UDR für das nächste
; Byte bereit ist
rjmp serout_string_wait
out UDR, r0
adiw zh:zl, 1 ; Zeiger erhöhen
rjmp serout_string ; nächstes Zeichen bearbeiten
serout_string_ende:
ret ; zurück zum Hauptprogramm
; Hier wird jetzt der String definiert und im Flash gespeichert
my_string: .db "Test!", 10, 13, 0
Empfangen von Zeichen per Polling
Der AVR kann nicht nur Daten seriell senden, sondern auch empfangen. Dazu muss man, nachdem die Baudrate wie oben beschrieben eingestellt wurde, das Bit RXEN setzen.
Sobald der UART ein Byte über die serielle Verbindung empfangen hat, wird das Bit RXC im Register UCSRA gesetzt, um anzuzeigen, dass ein Byte im Register UDR zur Weiterverarbeitung bereitsteht. Sobald es aus UDR gelesen wurde, wird RXC automatisch wieder gelöscht, bis das nächste Byte angekommen ist.
Das erste einfache Testprogramm soll das empfangene Byte auf den an Port D angeschlossenen LEDs ausgeben. Dabei sollte man daran denken, dass PD0 (RXD) bereits für die Datenübertragung zuständig ist, so dass das entsprechende Bit im Register PORTD keine Funktion hat und damit auch nicht für die Datenanzeige verwendet werden kann.
Nachdem der UART konfiguriert ist, wartet das Programm einfach in der Hauptschleife darauf, dass ein Byte über den UART ankommt (z. B. indem man im Terminalprogramm ein Zeichen eingibt), also RXC gesetzt wird. Sobald das passiert, wird das Register UDR, in dem die empfangenen Daten stehen, nach temp eingelesen und an den Port D ausgegeben.
.include "m8def.inc"
.def temp = R16
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp
; Port D = Ausgang
ldi temp, 0xFF
out DDRD, temp
; Baudrate einstellen
ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp
; Frame-Format: 8 Bit
ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp
sbi UCSRB, RXEN ; RX (Empfang) aktivieren
receive_loop:
sbis UCSRA, RXC ; warten, bis ein Byte angekommen ist
rjmp receive_loop
in temp, UDR ; Empfangenes Byte nach temp kopieren
out PORTD, temp ; und an Port D ausgeben.
rjmp receive_loop ; zurück zum Hauptprogramm
Empfangen von Zeichen per Interrupt
Dieses Programm lässt sich allerdings noch verfeinern. Statt in der Hauptschleife auf die Daten zu warten, kann man auch veranlassen, dass ein Interrupt ausgelöst wird, sobald ein Byte angekommen ist. Das sieht in der einfachsten Form so aus:
.include "m8def.inc"
.def temp = R16
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
.org 0x00
rjmp main
.org URXCaddr ; Interruptvektor für UART-Empfang
rjmp int_rxc
; Hauptprogramm
main:
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp
; Port D = Ausgang
ldi temp, 0xFF
out DDRD, temp
; Baudrate einstellen
ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp
; Frame-Format: 8 Bit
ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp
sbi UCSRB, RXCIE ; Interrupt bei Empfang
sbi UCSRB, RXEN ; RX (Empfang) aktivieren
sei ; Interrupts global aktivieren
loop:
rjmp loop ; Endlosschleife
; Interruptroutine: wird ausgeführt, sobald ein Byte über das UART empfangen wurde
int_rxc:
push temp ; temp auf dem Stack sichern
in temp, UDR ; empfangenes Byte lesen,
; dadurch wird auch der Interrupt gelöscht
out PORTD, temp ; Daten ausgeben
pop temp ; temp wiederherstellen
reti ; Interrupt beenden
Diese Methode hat den großen Vorteil, dass das Hauptprogramm (hier nur eine leere Endlosschleife) andere Dinge erledigen kann, während der Controller Daten empfängt. Auf diese Weise kann man mehrere Aktionen quasi gleichzeitig ausführen, da das Hauptprogramm nur kurz unterbrochen wird, um die empfangenen Daten zu verarbeiten.
Probleme können allerdings auftreten, wenn in der Interruptroutine die gleichen Register verwendet werden wie im Hauptprogramm, da dieses ja an beliebigen Stellen durch den Interrupt unterbrochen werden kann. Damit sich aus der Sicht der Hauptschleife durch den Interruptaufruf nichts ändert, müssen alle in der Interruptroutine geänderten Register am Anfang der Routine gesichert und am Ende wiederhergestellt werden. Das gilt vor allem für das CPU-Statusregister (SREG)! Sobald ein einziger Befehl im Interrupt ein einziges Bit im SREG beeinflusst, muss das SREG gesichert werden. Das ist praktisch fast immer der Fall, nur in dem ganz einfachen Beispiel oben ist es überflüssig, weil die verwendeten Befehle das SREG nicht beeinflussen. In diesem Zusammenhang wird der Stack wieder interessant. Um die Register zu sichern, kann man sie mit push oben auf den Stapel legen und am Ende wieder in der umgekehrten Reihenfolge(!) mit pop vom Stapel herunternehmen.
Im folgenden Beispielprogramm werden die empfangenen Daten nun nicht mehr komplett angezeigt. Stattdessen kann man durch Eingabe einer 1 oder einer 0 im Terminalprogramm eine LED (an PB0) an- oder ausschalten. Dazu wird das empfangene Byte in der Interruptroutine mit den entsprechenden ASCII-Codes der Zeichen 1 und 0 (siehe 4n7.eu/ascii.html oder Wikipedia) verglichen.
Für den Vergleich eines Registers mit einer Konstanten gibt es den Befehl cpi register, konstante. Das Ergebnis dieses Vergleichs kann man mit den Befehlen breq label (springe zu label, falls gleich) und brne label (springe zu label, falls ungleich) auswerten.
.include "m8def.inc"
.def temp = R16
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate
; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille
.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
.org 0x00
rjmp main
.org URXCaddr
rjmp int_rxc
; Hauptprogramm
main:
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp
; Port B = Ausgang
ldi temp, 0xFF
out DDRB, temp
; Baudrate einstellen
ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp
; Frame-Format: 8 Bit
ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp
sbi UCSRB, RXCIE ; Interrupt bei Empfang
sbi UCSRB, RXEN ; RX (Empfang) aktivieren
sei ; Interrupts global aktivieren
loop:
rjmp loop ; Endlosschleife
; Interruptroutine: wird ausgeführt, sobald ein Byte über das UART empfangen wurde
int_rxc:
push temp ; temp auf dem Stack sichern
in temp, sreg ; SREG sichern
push temp
in temp, UDR ; UART-Daten lesen
cpi temp, '1' ; empfangenes Byte mit '1' vergleichen
brne int_rxc_1 ; wenn nicht gleich, dann zu int_rxc_1
cbi PORTB, 0 ; LED einschalten, low-aktiv
rjmp int_rxc_2 ; Zu int_rxc_2 springen
int_rxc_1:
cpi temp, '0' ; empfangenes Byte mit '0' vergleichen
brne int_rxc_2 ; wenn nicht gleich, dann zu int_rxc_2
sbi PORTB, 0 ; LED ausschalten, low-aktiv
int_rxc_2:
pop temp
out sreg, temp ; SREG wiederherstellen
pop temp ; temp wiederherstellen
reti
Handshake
Werden Daten schnell über eine serielle Leitung an ein langsames Gerät übertragen, dann kann es passieren, dass die Situation eintritt, dass das empfangende Gerät nicht mehr mitkommt. Das kann z. B. dadurch passieren, dass das empfangende Gerät selbst etwas Zeit für die Bearbeitung der Daten benötigt. Man denke z. B. an die Situation, dass an ein Modem Daten übertragen werden. Das Modem muss diese Daten bearbeiten und unter Umständen über eine langsame Telefonleitung absetzen. Überträgt der AVR seine Daten mit voller Geschwindigkeit an das Modem, so wird auch dem besten Modem irgendwann der interne Speicher ausgehen, in dem es die Daten zwischenspeichern kann.
Was benötigt wird, ist also eine Möglichkeit, wie die Gegenstelle dem Sender signalisieren kann: „Bitte jetzt nichts senden, ich bin beschäftigt!“. Die einfachste Form eines derartigen Protokolls nennt sich Handshake. Es gibt bei RS232 zwei Arten, wie dieses Handshake implementiert werden kann: Software-Handshake und Hardware-Handshake.
Hardware-Handshake
Das Hardware-Handshake benutzt die beiden Steuerleitungen RTS (Request to Send) und CTS (Clear to Send), um die Flusskontrolle durchzuführen.
Die etwas seltsam anmutenden Namen haben historische Ursache. Ursprünglich war RS232 dazu gedacht, ein Modem (ein sog. Data Carrier Equipment oder DCE) an einen Endpunkt (DTE oder Data Terminal Equipment) anzuschließen. Wenn das DTE Daten senden wollte, aktivierte es die Leitung RTS, es fragte praktisch beim DCE an: „Darf ich senden?“ (engl. Request sending). Wenn das DCE bereit war, dann aktivierte es seinerseits die CTS-Leitung und signalisierte damit „Alles OK. Daten marsch!“ (engl. Clear to send). Solange das DCE nicht bereit war, Daten entgegenzunehmen, musste das DTE warten, bis es vom DCE die Freigabe zum Senden bekam.
- Für das DTE gilt: RTS ist ein Ausgang, CTS ist ein Eingang.
- Für das DCE gilt: RTS ist ein Eingang, CTS ist ein Ausgang.
Das war die ursprüngliche Idee. Heutzutage ist es aber normal, dass zwei DTE miteinander über eine RS232-Verbindung gekoppelt werden. Wird in so einem Fall Hardware-Handshake benutzt, so muss jedes DTE seiner Gegenstelle eine korrekte Bedienung der RTS-/CTS-Leitung vortäuschen.
Der Teil, dass CTS nur dann bedient wird, wenn über RTS die Anfrage nach der Sendefreigabe erfolgt, entfällt dabei. Jeder Gesprächspartner überprüft ganz einfach vor dem Sendevorgang den Zustand der CTS-Leitung der Gegenstelle, während der eigene RTS-Ausgang zur Signalisierung der Empfangsbereitschaft für die Gegenstelle dient. Dies ist auch der Grund, warum bei einem Null-Modem-Kabel nicht nur die RX-/TX-Leitungen, sondern auch die RTS-/CTS-Leitungen gekreuzt werden müssen.
Möchte man obige Schaltung um eine Hardware-Flusskontrolle erweitern, so bietet es sich an, die beiden noch freien Kanäle des MAX232 dafür zu verwenden. Die Schaltung sieht dann wie folgt aus:
Am ATmega8 stehen dann die Signale RTS bzw. CTS an den Pins PD4 bzw. PD5 zur Verfügung. An PD5 kann abgefragt werden, ob die Gegenstelle zum Empfang von Daten bereit ist, während der ATmega8 über PD4 signalisieren kann, dass er im Moment keine Daten über die serielle Schnittstelle empfangen kann.
Bedenken sollte man dabei allerdings, dass es nach der Rücknahme der Empfangsbereitschaft je nach Gegenstelle dazu kommen kann, dass noch ein paar Zeichen über die UART eintreffen. Wird z. B. der Zustand der RTS-Leitung vom Füllgrad eines Puffers abhängig gemacht, dann sollte man RTS nicht erst dann abschalten, wenn der Puffer komplett gefüllt ist, sondern schon ein paar Zeichen früher. Ursache könnte z. B. sein, dass die Gegenstelle über eine Hardware-UART verfügt, die einen internen Puffer besitzt. Hat die Gegenstelle erstmal diesen Hardware-Puffer gefüllt, dann gibt es oft keine Möglichkeit mehr für das dortige Programm, diese UART-Hardware zu stoppen – die Zeichen, die in die UART übertragen wurden, werden auf jeden Fall von der Hardware ausgegeben.
Software-Handshake
Ein Software-Handshake benutzt die Datenleitung selbst, um die Flusskontrolle von Sender/Empfänger zu erreichen. Dazu wurden im ASCII-Code zwei spezielle „Zeichen“ vorgesehen: XON (mit dem Code 0x11) und XOFF (mit dem Code 0x13).
Bemerkt ein Empfänger, dass er in Kürze keine Daten mehr vom Sender aufnehmen kann, dann sendet er seinerseits ein XOFF, woraufhin der Sender das Senden der Daten unterbricht. Ist der Empfänger wieder aufnahmebereit, so gibt er die Übertragung durch das Senden eines XON wieder frei.
Der Nachteil des Software-Handshaking besteht also in mehreren Punkten:
- Zum einen können nicht mehr alle Datenbytes übertragen werden, da ja die Bytes 0x11 und 0x13 eine spezielle Bedeutung haben. Möchte man Bytes binär übertragen, muss man daher spezielle Vorkehrungen treffen, damit diese Datenbytes nicht durch das Software-Handshaking fehlinterpretiert werden.
- Zum anderen muss jeder Sender, während er sendet, auch gleichzeitig einen möglichen Empfang von Daten überwachen. Die Gegenstelle könnte ja mittels XOFF eine kurzfristige Unterbrechung der Sendung anfordern. Auch muss jeder Sender exakt darüber Buch führen, ob die Leitung zur Zeit im Status XOFF liegt und ob daher Übertragungen überhaupt möglich sind.
- Das Senden von XOFF muss rechtzeitig erfolgen. Denn meistens benötigt die Gegenstelle etwas Zeit, um das Senden einzustellen. Es kann durchaus sein, dass nach einem XOFF noch ein paar Zeichen von der Gegenstelle eintreffen.
- Es besteht die Gefahr eines Deadlocks, indem sich beide Seiten gegenseitig mit einem XOFF blockieren, aus dem sie nicht mehr herauskommen.