Seriell Schnittstelle Steuerleitungen

[traffic (Gast)]

Hi,

ich muss die Steuerleitungen der seriellen Schnittstelle recht 
zeitkritisch abfragen. Da ich das nicht unbedingt per Polling machen 
will, die Frage: Gibt es für C unter Linux da eine Interrupt-gesteuerte 
Möglichkeit?

LG
traffic

[Jörg W. (dl8dtl) (Moderator)]

Die gibt's im normalen Posix-Modell nur für die DCD-Leitung: im
„normalen“ Modembetrieb bekommst du ein SIGHUP (“hangup”), wenn
DCD verschwindet.

Allerdings muss der zugrhörige Prozess zuvor der process group leader
für das entsprechende Terminal geworden sein (via setpgid() und
tcsetpgrp()).

[H. K. (spearfish)]

Ich gehe mal davon aus, dass du das auslesen per TTY Syscalls (ioctl) 
machst.
Da gibt es den TIOCMIWAI-Syscall.

Siehe die Doku: http://man7.org/linux/man-pages/man4/tty_ioctl.4.html

       TIOCMIWAIT     int arg
              Wait for any of the 4 modem bits (DCD, RI, DSR, CTS) to
              change.  The bits of interest are specified as a bit mask in
              arg, by ORing together any of the bit values, TIOCM_RNG,
              TIOCM_DSR, TIOCM_CD, and TIOCM_CTS.  The caller should use
              TIOCGICOUNT to see which bit has changed.

Logischerweise musst du dann diesen Syscall in einen Child-Prozess 
auslagern, wenn du nicht willst, dass dein Programm blockiert...

Siehe z.B. hier für ein Beispielprogramm: 
http://linux.mathematik.tu-darmstadt.de/pub/linux/oldstuff/people/bonnes/waitcomm/serial_test.c

[Peter II (Gast)]

H. K. schrieb:
> Logischerweise musst du dann diesen Syscall in einen Child-Prozess
> auslagern, wenn du nicht willst, dass dein Programm blockiert...

Linux kann doch mittlerweile auch Threads.

[H. K. (spearfish)]

Peter II schrieb:
> Linux kann doch mittlerweile auch Threads.

Stimmt. Habe ich vergessen zu erwähnen!

[Eric B. (beric)]

traffic schrieb:
> ich muss die Steuerleitungen der seriellen Schnittstelle recht
> zeitkritisch abfragen.

Wie kritisch ist denn die Zeit? Linux ist, wie alle andere Desktop und 
Server OS-en, nicht gerade ausgelegt für zeitkritische (Real-time) 
Anforderungen.

[traffic (Gast)]

Danke für die Antworten.

Leider bin ich irgendwie zu blöd, folgender Test-Code kommt bei mir nur 
bis zur Ausgabe "TEST":

#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main()
{
  int fd;
  struct termios options;
  fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY);
  if(fd == 0)
  {
    printf("Fehler: Device kann nicht geöffnet werden.\n");
    return 1;
  }
  
  memset(&options,0,sizeof (struct termios));
  cfmakeraw(&options);
  cfsetispeed(&options,B9600);
  cfsetospeed(&options,B9600);
  tcsetattr(fd,TCSANOW,&options);
  tcflush(fd,TCIOFLUSH);
    
  int i;
  printf("TEST\n");
  i = ioctl(fd,TIOCMIWAIT,0);
  if( i < 0 )
  {
    printf("clear failed (%d)\n",i);
    return 1;
  }
  else
    printf("PASS\n");
  i = ioctl(fd, TIOCMIWAIT, TIOCM_DSR);
  printf("A=%d", i);
  
  close(fd);
  return 0;
}

LG
traffic

[Jörg W. (dl8dtl) (Moderator)]

traffic schrieb:
> ioctl(fd,TIOCMIWAIT,0);

Nun, wenn du auf nichts wartest (0), dann ist das wohl wenig
sinnvoll.  Die Funktion kann daraus zwei Entscheidungen treffen:
sofort zurückkehren („nichts“ ist ja bereits eingetreten), oder
unendlich warten („nichts“ kann nie eintreten).  Offenbar tut sie
letzteres.

[traffic (Gast)]

Naja, dem verlinkten Beispiel nach müsste es gehen:

/* clear the wait flags */
    r = ioctl(fd,TIOCMIWAIT,0);
    if( r < 0 )
    {
        fprintf(stderr,"clear failed (%d)\n",r);
        return 1;
    }

[Jörg W. (dl8dtl) (Moderator)]

Beitrag "Re: Seriell Schnittstelle Steuerleitungen"

[nicht“Gast“ (Gast)]

traffic schrieb:
> zeitkritisch

traffic schrieb:
> "/dev/ttyUSB0"

Bist du dir mit den zeitkritisch sicher? So recht passt das nicht 
zusammen. Wie viel Zeit kannst du dir denn gönnen?

[Jörg W. (dl8dtl) (Moderator)]

nicht“Gast“ schrieb:
> So recht passt das nicht zusammen.

Die Zeiten, die für die Meldung über den USB benötigt werden, dürften
im Bereich 10 ms liegen (hängt natürlich vom konkreten Device ab, das
er uns nicht genannt hat).  So schnell muss man es erstmal auf der
Ebene des Programms schaffen in einem nicht-realtime-OS.

[traffic (Gast)]

Die Zeit zum Erkennen einer Pegeländerung beträgt 30-40 ms. USB ist hier 
nur zum Test drin.

[Pandur S. (jetztnicht)]

Wenn eine Handshake Funktion zeitkritisch ist, sollte sie bereits im 
Treiber implementiert sein, und nicht im Benutzerprogramm. Db das Buffer 
Full, im RTS/CTS. Sonst kann man im UART Fall von einem PC wenig 
erwarten. Versuch mal eine zunehmend laengere Blochnachricht zu 
uebertragen. Die kommt dann ploetzlich in einzelne Bloecke zerhackt. Mit 
einem eigenen Timing. Ich hab die Details dazu leider vergessen. Und der 
USB treiber macht auch noch seine Spielchen.

Fazit. Man sollte von einem PC keine Echtzeitleistungen erwarten.