Forum: Mikrocontroller und Digitale Elektronik Cortex-M UART im Polling-Betrieb


von Ralf (Gast)


Lesenswert?

Hi,

ich möchte den UART eines Cortex-M im Polling-Betrieb ansprechen. Der 
UART ist weitgehend zum 16550-UART kompatibel.

Was mich jetzt ein wenig verwirrt ist das LineStatus-Register. Dort sind 
einerseits die Statusbits für das im Rx-FIFO enthaltene Byte (sofern ein 
gültiges drin ist) drin, also beispielsweise ParityError, etc. und für 
den Tx-FIFO die Angabe, ob noch Platz im FIFO ist (THRE-Flag bzw. 
TEMT-Flag).

Wenn ich nun für das Senden mithilfe der THRE/TEMT-Flags ermitteln will 
ob der Tx-FIFO noch Platz hat, muss ich das LS-Register lesen. Das Lesen 
des Registers löscht aber gleichzeitig die Statusflags für das nächste 
Byte im Rx-FIFO, womit die Funktion für's Lesen des Rx-FIFOs die 
Status-Codes verliert.

Heisst dass jetzt, dass ich den UART nur per Interrupt sinnvoll bedienen 
kann oder gibt's doch ne Polling-Variante?
Das einzige was mir bisher einfiel war in der Sende-Funktion 
auszuwerten, ob ein Byte im Rx-FIFO ist (steht ebenfalls im LS-Register) 
und dies über eine globale Variable der Empfangs-Funktion zugänglich zu 
machen. Wenn was da war, liest die Empfangsroutine das LS-Register 
nicht, sondern nimmt den Wert aus der globalen Variablen.

Kann mir jemand auf die Sprünge helfen? :)

Ralf

von holger (Gast)


Lesenswert?

>ich möchte den UART eines Cortex-M im Polling-Betrieb ansprechen.

Wie schön das es nur einen Cortex-M gibt.
Auf der Frage wirst du wohl sitzen bleiben.

von Ralf (Gast)


Angehängte Dateien:

Lesenswert?

> Wie schön das es nur einen Cortex-M gibt.
> Auf der Frage wirst du wohl sitzen bleiben.
Auweia, stimmt ja, sorry!
NxP LPC1114 (M0), LPC1343 (M3), LPC1768 (M3).

Anbei auch mal der UserGuide des LPC11xx, auf dem probier ich's aktuell.

Ralf

von (prx) A. K. (prx)


Lesenswert?

Zustandsbits vom FIFO verändert sich erst durch Lesen/Schreiben vom 
FIFO. In der Annahme, dass die LPC1000 von den LPC2000 nicht weit weg 
sind:
1
void
2
UARTbase::put(char c)
3
{
4
    while (!(uart->lsr & UART_LSR_THRE)) {
5
        ;
6
    }
7
    uart->thr = c;
8
}
Wenn es darum geht, die übrigen Bits über Parityfehler etc. nicht zu 
verlieren, dann musst du die mit jedem Auslesen vom LSR in einer 
gemeinsamen Variable akkumulieren und im Receiver-Code auswerten. Die 
PC-UART hat eben ein paar konzeptionelle Macken.

von Ralf (Gast)


Lesenswert?

@prx:
> Wenn es darum geht, die übrigen Bits über Parityfehler etc. nicht zu
> verlieren, dann musst du die mit jedem Auslesen vom LSR in einer
> gemeinsamen Variable akkumulieren und im Receiver-Code auswerten.
Okay, also so wie ich oben dachte :)

Besten Dank und gute Nacht.

Ralf

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.