Raspberry Pi: UART - Blocking Write/Transmission Complete

[Matthias (Gast)]

Hallo,

ich möchte über die UART (/dev/ttyAMA0) des Raspberry Pi (Modell B v2.0) 
ein Byte senden.

Konfiguration:

rpiFd = open(FILE_PATH, O_RDWR | O_NOCTTY);

if(tcgetattr(rpiFd, &rpiOpt) != 0)

// set baud rate
// -------------
cfsetispeed(&rpiOpt, B9600);       
cfsetospeed(&rpiOpt, B9600);       

// control options
// ---------------
rpiOpt.c_cflag &= ~PARENB;        
rpiOpt.c_cflag &= ~PARODD;         
rpiOpt.c_cflag &= ~CSTOPB;        
rpiOpt.c_cflag &= ~CSIZE;        
rpiOpt.c_cflag |= CS8;        
rpiOpt.c_cflag |= CLOCAL;        
rpiOpt.c_cflag |= CREAD;        

// local options
// -------------
rpiOpt.c_lflag &= ~ICANON;    
rpiOpt.c_lflag &= ~(ECHO | ECHOE);  
rpiOpt.c_lflag &= ~ISIG;    
   
// input options
// -------------
rpiOpt.c_iflag |= INPCK;      
rpiOpt.c_iflag &= ~IGNPAR;      
rpiOpt.c_iflag |= PARMRK;
rpiOpt.c_iflag &= ~ISTRIP;
rpiOpt.c_iflag &= ~IXON;
rpiOpt.c_iflag &= ~IXOFF;
rpiOpt.c_iflag &= ~IXANY;  
rpiOpt.c_iflag &= ~IGNBRK;
rpiOpt.c_iflag &= ~BRKINT;
rpiOpt.c_iflag &= ~INLCR;  
rpiOpt.c_iflag &= ~IGNCR;
rpiOpt.c_iflag &= ~ICRNL;
rpiOpt.c_iflag &= ~IUCLC;
rpiOpt.c_iflag |= IMAXBEL;
    
// output options
// --------------
rpiOpt.c_oflag &= ~OPOST;
  
// control characters
// ------------------
rpiOpt.c_cc[VMIN] = 0;
rpiOpt.c_cc[VTIME] = 10;

tcflush(rpiFd, TCIOFLUSH);
tcsetattr(rpiFd, TCSANOW, &rpiOpt);

Code zum Senden:

uint8_t data = 0x00;

bcm2835_gpio_write(RPI_V2_GPIO_P1_11, HIGH);
write(rpiFd, &data, 1);
// tcdrain(rpiFd);
bcm2835_gpio_write(RPI_V2_GPIO_P1_11, LOW);

Problem:
Ich möchte beim Senden des Bytes solange blockieren, bis das Byte 
tatsächlich physikalisch über die UART gesendet wurde (inkl. Stoppbit). 
Um dies zu überprüfen, ziehe ich einen GPIO vor dem Funktionsaufruf auf 
HIGH und im Anschluss wieder auf LOW. Das Ergebnis ist im Anhang 
(write.png) zu sehen. Oben sieht man die Übertragung des Bytes über die 
UART, unten den GPIO. Wie zu erkennen ist, blockiert die write-Funktion 
nicht einmal so lange, bis das Startbit übertragen wurde.

Als vermeintliche Lösung bin ich auf die Funktion tcdrain() gestoßen. 
Diese soll warten, bis alle Daten gesendet wurden. Damit erhalte ich 
dann das Ergebnis im Anhang (write_tcdrain.png). Wie zu erkennen ist, 
blockiert tcrdain() in der Tat, allerdings um ein Vielfaches länger, als 
es müsste - etwa 12ms anstatt ca. 1ms.

Frage:
Gibt es eine Möglichkeit nach dem Schreiben nur genau solange zu 
blockieren, bis das Senden des Bytes vollständig abgeschlossen ist? (Bei 
einem uC würde man einfach ein TX oder BUSY-Flag pollen oder auf einen 
entsprechenden Interrupt warten...)

Danke im Voraus!

Gruß,
Matthias

[Matthias (Gast)]

Sorry, da ging die Dateiendung der Grafiken vergessen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

@ Matthias: "Projekte und Code" ist für fertige Projekte gedacht. 
Siehe Screenshot von der Überschrift...

[Peter II (Gast)]

Matthias schrieb:
> Frage:
> Gibt es eine Möglichkeit nach dem Schreiben nur genau solange zu
> blockieren, bis das Senden des Bytes vollständig abgeschlossen ist?

ich hatte so ein ähnliches Problem auch schon. Aber ich habe dafür auch 
keine schöne Lösung gefunden. Ich habe mir anhand der Anzahl der Bytes 
und der Baudrate die Übertragungszeit ausgerechnet und vor dem Start der 
Übertragung die Systemzeit geholt. und dann die Differenz zwischen den 
beiden Zeiten gewartet.

Bei mir ging es aber um einen USB-Serial Adapter diese hat recht viel 
Puffer gehabt.

[suri (Gast)]

Matthias schrieb:
> Frage:
> Gibt es eine Möglichkeit nach dem Schreiben nur genau solange zu
> blockieren, bis das Senden des Bytes vollständig abgeschlossen ist? (Bei
> einem uC würde man einfach ein TX oder BUSY-Flag pollen oder auf einen
> entsprechenden Interrupt warten...)

Welchen Hintergrund hat das? Warum will man so ein Verhalten?

[Matthias (Gast)]

@Peter II:
Ja, so etwas habe ich mir auch schon überlegt. Ist natürlich - wie du 
schon selbst gesagt hast - keine "schöne" und robuste Lösung.

Ich hätte auch nicht gedacht, dass es so schwer sein könnte, so eine 
doch relativ einfache Information, die die UART-Hardware ja direkt 
bereitstellt, durch das Betriebssystem bis in den eigenen Code 
weiterzugeben...

Wenn man sich den UART-Treiber im Linux-Kernel anschaut 
(linux/drivers/tty/serial/amba-pl011.c), dann gibt es da tatsächlich 
sogar eine Funktion

pl011_console_write()

, die eigentlich genau das macht, was ich brauche - Byte an die UART 
senden und dann das UART01x_FR_BUSY Flag pollen, bis das Byte versendet 
wurde.

Leider wird diese Funktion beim Senden gar nicht benutzt und ich weiß 
auch nicht, wie man die serielle Schnittstelle dafür konfigurieren 
müsste.

@suri:
Der Hintergrund ist der Folgende: Nach dem Versenden des Bytes will ich 
die UART schnellst möglichst umkonfigurieren. Und damit ich 
umkonfigurieren kann muss ich sicher wissen, dass die vorangegangene 
Operation, also das Versenden des Bytes, sicher abgeschlossen ist.

[(prx) A. K. (prx)]

suri schrieb:
> Welchen Hintergrund hat das? Warum will man so ein Verhalten?

Abschalten eines RS485 transceivers?

Abfragen lässt es sich jedenfalls. Im FR Register der zuständigen UART 
gibts ein BUSY Bit.

[Matthias (Gast)]

A. K. schrieb:
> Abfragen lässt es sich jedenfalls. Im FR Register der zuständigen UART
> gibts ein BUSY Bit.

Ja genau. Die Hardware gibt es her. Jetzt suche ich noch eine 
Möglichkeit diese Info auch oberhalb des Betriebssystems zu nutzen

[(prx) A. K. (prx)]

Matthias schrieb:
> Ja genau. Die Hardware gibt es her. Jetzt suche ich noch eine
> Möglichkeit diese Info auch oberhalb des Betriebssystems zu nutzen

Man kann sich vom Anwenderprogramm aus direkt einen Zugriff auf die 
Register des SOC verschaffen.

[Matthias (Gast)]

A. K. schrieb:
> Man kann sich vom Anwenderprogramm aus direkt einen Zugriff auf die
> Register des SOC verschaffen.

Um die Software portabel und hardware-unabhängig zu halten, möchte ich 
genau das vermeiden! Ich dachte man könnte die gewünschte Information 
auch über standardisierte Schnittstellen wzb. termios oder system calls 
erfragen.

[suri (Gast)]

Matthias schrieb:

> @suri:
> Der Hintergrund ist der Folgende: Nach dem Versenden des Bytes will ich
> die UART schnellst möglichst umkonfigurieren. Und damit ich
> umkonfigurieren kann muss ich sicher wissen, dass die vorangegangene
> Operation, also das Versenden des Bytes, sicher abgeschlossen ist.

Ok, das ist ein Grund. RS485-Transveiver umschalten auch.

Ich würde mit dem Anliegen incl. Begründung mal in die Kernel Mailing 
Liste gehen. Allerdings ist ein Zeitverhalten durch den Kernel nicht 
garantiert.
Oder da nachfragen ob die starke Verzögerung bei tcrdain() gewollt ist.

[(prx) A. K. (prx)]

Matthias schrieb:
> Ich dachte man könnte die gewünschte Information
> auch über standardisierte Schnittstellen wzb. termios oder system calls
> erfragen.

Es scheint dafür keinen Interrupt zu geben, was die Sache für den Kernel 
nicht eben erleichtert.

[Matthias (Gast)]

Danke für die Rückmeldungen!

Ich habe soeben eine für mich ausreichend gute Lösung gefunden:

Mit der Betriebssystemfunktion ioctl() kann ich mir das Line Status 
Register (LSR) der UART auslesen lassen. Dieses enthält ein Flag 
(TIOCSER_TEMT) welches angibt, ob sich noch physikalisch Bits im 
Ausgangsshiftregister der UART befinden. Dieses kann ich nun mit meinem 
Code wunderbar pollen:

uint8_t lsr;
uint8_t data = 0x00;

bcm2835_gpio_write(RPI_V2_GPIO_P1_11, HIGH);
write(rpiFd, &data, 1);

do
{
  ioctl(fd, TIOCSERGETLSR, &lsr);
}
while ( !(lsr&TIOCSER_TEMT) );

bcm2835_gpio_write(RPI_V2_GPIO_P1_11, LOW);

Das liefert mir genau das gewünschte Verhalten ohne, dass ich selbst mit 
Adressen direkt auf die UART-Hardwareregister zugreifen muss. Die 
Schleife wird immer sauber sofort nach dem Stoppbit verlassen (siehe 
Anhang)!

Grüße,
Matthias