AVR-Tutorial: UART

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

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:

UART/MAX232-Standardbeschaltung

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).
Kabelbeschaltungen

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

hyperterminal.gif

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.

RS232 orig.png

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.

RS232 dte.png

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:

UART/MAX232-Beschaltung für RTS/CTS am Beispiel eines ATmega16. Achtung: Pinbelegung an den ATmega8 anpassen!

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.

Weblinks