Linux: Serielle Schnittstelle programmieren

[Tobias P. (hubertus)]

Hallo

Ich habe mir einen GPIB-USB Adapter gekauft. Auf meinem Windows-Rechner, 
an dem ich zur Zeit sitze, funktioniert der super: er meldet sich als 
COM6 an und ich kann z.B. mit TeraTerm auf den GPIB Bus zugreifen und 
Kommandos absetzen und bekomme die erwarteten Antworten. Mit Linux (hier 
in der VM) geht es auch, wenn ich es so mache:

http://heliosoph.mit-links.info/gpib-on-debian-linux-the-easy-way/

ich will jetzt aber eine eigene Applikation schreiben, welche auf den 
GPIB zugreift, um ein bestimmtes Gerät zu steuern. Daher versuche ich 
jetzt in der Linux-VM (es soll später mal auf Linux laufen, habe aber 
grade keinen Linux Rechner zur Hand) ein C-Programm zu schreiben, 
welches den Port ansteuert, also Kommandos absetzt und die Antworten 
auswertet. Leider funktioniert das nicht wie erwartet, es werden immer 
wieder ganze Textteile verschluckt, und der Code hängt sich teilweise 
auf. Ist für mich nicht reproduzierbar, wieso. Kann einer einen tipp 
geben? bis jetzt sieht mein Code so aus:

#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <string.h>
#include <stdio.h>

void gpib_write(int fd, const char* str)
{
  write(fd, str, strlen(str));
}

int gpib_read(int fd, char* buf)
{
  int i;
  int len = 0;
  int rep = 1;
  while(rep)
  {
    i = read(fd, buf, 1);
    if(i==0)
    {
      rep = 0;
    }
    buf++;
    len++;
    *buf = 0;
  }
  return len;
}

int main(void)
{
  int fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
  if(fd == -1)
  {
    printf("failed to open /dev/ttyS0");
  }
  
  struct termios options;
  tcgetattr(fd, &options);
  options.c_cflag = B9600 | CS8 | CLOCAL | CREAD;
  options.c_lflag &= ~ICANON; /* Set non-canonical mode */
  options.c_cc[VTIME] = 10; /* Set timeout of 10.0 seconds */
  tcflush(fd, TCIFLUSH);
  tcsetattr(fd, TCSANOW, &options);

  gpib_write(fd, "++ver\r\n");
  char testtest[1000];
  gpib_read(fd, testtest);
  printf("%s", testtest);
  
  close(fd);
  return 0;
}

Der ++ver-Befehl z.B. funktioniert, er liefert:

Prologix GPIB-USB Controller version 6.101

Aber z.B. der ++help Befehl funktioniert nur mit TeraTerm auf Windows: 
Er sollte

The following commands are available:
++addr 0-30 [96-126]  -- specify GPIB address
++addr                -- query GPIB address
++auto 0|1            -- enable (1) or disable (0) read-after-write
++auto                -- query read-after-write setting
++clr                 -- issue device clear
++eoi 0|1             -- enable (1) or disable (0) EOI with last byte
++eoi                 -- query eoi setting
++eos 0|1|2|3         -- EOS terminator - 0:CR+LF, 1:CR, 2:LF, 3:None
++eos                 -- query eos setting
++eot_enable 0|1      -- enable (1) or disable (0) appending eot_char on EOI
++eot_enable          -- query eot_enable setting
++eot_char <char>     -- specify eot character in decimal
++eot_char            -- query eot_char character
++ifc                 -- issue interface clear
++loc                 -- set device to local
++lon                 -- enable (1) or disable (0) listen only mode
++mode 0|1            -- set mode - 0:DEVICE, 1:CONTROLLER
++mode                -- query current mode
++read [eoi|<char>]   -- read until EOI, <char>, or timeout
++read_tmo_ms 1-3000  -- set read timeout in millisec
++read_tmo_ms         -- query timeout
++rst                 -- reset controller
++savecfg 0|1         -- enable (1) or disable (0) saving configuration to EPROM
++savecfg             -- query savecfg setting
++spoll               -- serial poll currently addressed device
++spoll 0-30 [96-126] -- serial poll device at specified address
++srq                 -- query SRQ status
++status 0-255        -- specify serial poll status byte
++status              -- query serial poll status byte
++trg                 -- issue device trigger
++ver                 -- query controller version
++help                -- display this help

liefern, ich bekomme aber nur immer einzelne Zeilen oder garnichts. Was 
mache ich falsch?

[Tux (Gast)]

Vielleicht ist deine read-Methode zu langsam und der Puffer der 
Schnittstelle läuft über. Warum liest du immer nur 1 Byte? Lies größere 
Blöcke so wie es sich gehört.

[Kaj G. (Firma: RUB) (bloody)]

Tux schrieb:
> Lies größere Blöcke so wie es sich gehört.
Wo ist das eingemeisselt, das sich das so gehoert? Das kann jeder 
benutzen, wie er lustig ist, deswegen gibt es ja die moeglichkeit, 
anzugeben, wie viel man lesen moechte. Es gibt in diesem falle kein 
"richtig" oder "falsch" und somit auch kein "wie es sich gehoert!".

Tobias Plüss schrieb:
> int gpib_read(int fd, char* buf)
> {
>   int i;
>   int len = 0;
>   int rep = 1;
>   while(rep)
>   {
>     i = read(fd, buf, 1);
>     if(i==0)
>     {
>       rep = 0;
>     }
>     buf++;
>     len++;
>     *buf = 0;
>   }
Du solltest lieber gucken, ob ein bestimmtes Zeichen empfangen wurde, 
dass das Ende der Uebertragung signalisiert, z.B. das Null-Byte, ein 
Semikolon, oder was auch immer die gegenstelle halt als letztes Zeichen 
sendet. Nur weil read eine 0 zurueck gibt, heisst das ja nicht, das die 
uebertragung vorbei ist.

Upon successful completion, these functions shall return a non-negative integer indicating
the number of bytes actually read. Otherwise, the functions shall return -1 and set errno
to indicate the error.

Sprich: wenn read eine 0 liefert, heisst das lediglich, das gerade keine 
Daten gelesen wurden, vielleicht weil noch keine neuen Daten da waren.

Meine Konfiguration der Seriellen schnittstelle sieht etwas anders aus, 
als deine:

#include <fcntl.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <termios.h>
#include <unistd.h>

struct termios config;

int fd = open("/dev/deinDevice", O_RDWR | O_NOCTTY | O_NONBLOCK);

memset(&config, 0, sizeof(config));
config.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | INPCK | ISTRIP | IXON);
config.c_oflag = 0;
config.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
config.c_cflag &= ~(CSIZE | PARENB);
config.c_cflag |= CS8;
config.c_cc[VMIN]  = 1;
config.c_cc[VTIME] = 0;

cfsetispeed(&config, B115200);
cfsetospeed(&config, B115200);

char c;
while(c != ';')
{
  if( read(fd, &c, 1) > 0 )
  {
    // mach was mit dem Zeichen
  }
}

Mit der Konfiguration und dem Lesen hab ich unter Linux keine Probleme.

Schau mal hier:
https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux
https://en.wikibooks.org/wiki/Serial_Programming/termios

[Tobias P. (hubertus)]

Hi Kaj,

habe das bei mir ausprobiert. Der Code funktioniert schon, aber er hat 
eigentlich das selbe Problem wie mein Code:
ich rufe zuerst write auf und sende einen Befehl, und auf der nächsten 
Zeile will ich mit read die Empfangsdaten holen. Aber die werden mir 
einfach zerstückelt, ich krieg das nicht gebacken hier. Entweder müsste 
man noch was  konfigurieren oder aber es geht so nicht. Gibt es 
allenfalls eine Library?

[Karl H. (kbuchegg)]

Tobias Plüss schrieb:
> Hi Kaj,
>
> habe das bei mir ausprobiert. Der Code funktioniert schon, aber er hat
> eigentlich das selbe Problem wie mein Code:
> ich rufe zuerst write auf und sende einen Befehl, und auf der nächsten
> Zeile will ich mit read die Empfangsdaten holen. Aber die werden mir
> einfach zerstückelt,

Genau damit musst du rechnen.
Ein read kann nur das aus dem Buffer der Seriellen Schnittstelle 
auslesen, was schon an Daten eingelaufen ist!

Dein Rechner arbeitet aber um Zehnerpotenzen schneller als die 
Datenübertragung dauert. D.h. du wirfst einen Brief in den Postkasten, 
auf dass ihn der Briefträger mitnimmt und 10 Sekunden nach dem Einwerfen 
siehst du im Briefkasten nach, ob schon Antwort da ist. Das kann nicht 
funktionieren! Du musst dem Zeug schon Zeit geben, damit
* dein Kommando an das Gerät übertragen wird
* das Gerät das Kommando ausführen kann
* die Antwort auch zurückünermittelt werden kann
* damit rechnen, dass du nicht die komplette Antwort in einem einzigen
read Aufruf kriegst.

> ich krieg das nicht gebacken hier.

Wie schliesst denn das Gerät jede Antwort ab?
Da hier ASCII im Spiel ist, würde ich mal vermuten, dass das Gerät eine 
Angtwort mit einem \r\n abschliesst, genauso wie du dein Kommando mit 
einem \r\n abschliessen musstest.

Du musst also solange lesen (*), bis du ein \n als Antwort kriegst. 
Selbst wenn da read Aufrufe zwischendurch dabei waren, die 0 Bytes 
gelesen haben. Die haben deswegen 0 Bytes gelesen, weil die Antwort oder 
Teile davon noch unterwegs waren (bzw, noch gar nicht vom Gerät 
abgesendet wurden) zum Zeitpunkt an dem du read aufgerufen hast.

> Entweder müsste
> man noch was  konfigurieren

Das hat nichts mit der Konfiguration zu tun, sondern damit das Dinge 
Zeit brauchen und dein Computer rasend schnell dein Programm ausführen 
kann. Viel schneller als Daten übertragen werden können.


> oder aber es geht so nicht. Gibt es
> allenfalls eine Library?

Kopfschüttel.
Denkst du nicht, das es besser wäre die Dinge zu verstehen und richtig 
zu programmieren, anstatt immer nach einer Lib zu rufen? Das ist alles 
kein Hexenwerk sondern das kleine EinmalEins der Datenkommunikation. 
Wenn du so willst, das 'Seepferdchen' in der Ansteuerung externer 
Geräte.


(*) und das jeweils Gelesene natürlich zu einem komplettn String 
zusammensetzen.

[Karl H. (kbuchegg)]

int gpib_read(int fd, char* buf)
{
  int i;
  int len = 0;
  char c = ' ';

  do {
    i = read(fd, &c, 1);
    if( i != 0 ) {
      *buf++ = c;
      len++;
    }
  } while( c != '\n' );

  *buf = '\0';

  return len;
}

Zur Fehlerbehandlung solltest du noch die Länge des Buffers in die 
Funktion mit reingeben und in der Schleife potentielle Array Overflows 
abfangen.

[Tobias P. (hubertus)]

Hallo zusammen

deinen Einwand, Karl Heinz, dass es besser wäre, die Dinge zu verstehen, 
teile ich natürlich absolut. Ich selbst bin auch jeweils dieser Ansicht. 
In diesem Fall ist jedoch die Serielle Schnittstelle nur ein 
Nebenkriegsschauplatz, es geht gar nicht um diese, sondern es geht halt 
dann darum, dass ich die GPIB-Kommunikation darüber abwickeln will. :-)
Aber du hast schon recht.

Ich schau mir deinen Code gleich mal durch. Das dumme beim GPIB:
ich habe bisher noch kein System erkennen können, wie das Gerät die 
Antwort abschliesst. Einige Befehle liefern in der Tat nur eine einzige 
Zeile zurück, die mit CR + LF endet, und einige spezielle Befehle 
liefern aber mehrere Strings zurück. Wenn ich z.B. vom Oszilloskop die 
Messpunkte über den GPIB ausgeben lasse, dann kommt da natürlich eine 
zweispaltige Liste mit der Zeit in der ersten und der Spannung in der 
zweiten Spalte, und das über mehrere Zeilen.

[Karl H. (kbuchegg)]

Tobias Plüss schrieb:

> Messpunkte über den GPIB ausgeben lasse, dann kommt da natürlich eine
> zweispaltige Liste mit der Zeit in der ersten und der Spannung in der
> zweiten Spalte, und das über mehrere Zeilen.

Wobei jede Zeile wieder mit einem CR+LF abgeschlossen ist.
Das trickreiche wird jetzt sein: woher wissen wir, wieviele Zeilen das 
sind?

Gibt es da keine Header Zeile, in der die Anzahl der folgenden 
Tabellen-Zeilen drinn steht?
Manchmal gibt es bei Geräten auch ein eigenes Kommando, mit dem man im 
Vorfeld abfragen kann, wie gross die eigentliche Antwort dann sein wird.


Eine Zeile lesen zu können ist ja erst der Anfang. Niemand sagt, dass 
das bereits alles wäre um eine Kommunikation zustande zu kriegen.

[Karl H. (kbuchegg)]

Übrigens sollte man beim read einen Return Wert von -1 auch extra 
behandeln. Denn

The function returns the number of bytes read. On end-of-file, 0
is returned, on error it returns -1, setting errno to indicate the
type of error that occurred.

Lass dich nicht von 'End Of File' verwirren. Das ist für echte Files 
gedacht. Bei einer Seriellen abstrahiert das zu einem einfachen: Ich hab 
momentan nichts mehr, was man auslesen könnte.
'Momentan' bedeutet aber nicht, dass das ein paar Millisekunden später 
nicht ganz anders sein könnte.

[Tobias P. (hubertus)]

Hmm ich stelle grade fest, dass das Problem vielleicht woanders liegt. 
Ob ich eventuell an meinem BS noch was konfigurieren muss? es scheint 
generell Probleme zu huaben mit USB/Seriell Wandlern.

Interessant: auf dem Büro-Notebook läuft alles, unter Windows. Dort in 
der Linux-VM läuft es halbwegs. Jetzt bin ich zu Hause an meinem 
Privat-Notebook, und dort geht es gar nicht, nicht mal mit Matlab mit 
den Befehlen serial(), fprintf() und fgets(). Irgendwas ist mit dieser 
Schnittstelle faul.

[Gerd B. (bertr2d2)]

Hallo,

warum benutzt Du eigentlich 'non-canonical' Modus wobei doch
die Daten zeilenbasiert sind ?
Das Lesen einzelner Zeichen ist zudem ineffizient - es ist besser
so viele Zeichen auf einmal zu Lesen wie vorhanden sind. Man sollte
nicht gegen die Optimierungen des Betriebsystems arbeiten.

Siehe:
http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/x115.html

BTW: Richard Stevens hat ein sehr empfehlenswertes Buch geschrieben
in dem er u.a. auf die verschiedenen Methoden zum Lesen von Devices
eingeht:
"Advanced Programming in the UNIX Environment"

Gruß

Gerd

[A. H. (ah8)]

Kaj G. schrieb:

int fd = open("/dev/deinDevice", O_RDWR | O_NOCTTY | O_NONBLOCK);

...

char c;
while(c != ';')
{
  if( read(fd, &c, 1) > 0 )
  {
    // mach was mit dem Zeichen
  }
}

Warum öffnest Du denn den Port im non-blocking Mode, nur um dann in 
einer Schleife ständig abzufragen, ob ein Zeichen da ist? Das ist reine 
Beschäftigungstherapie für den Rechner und dürfte Dir völlig 
unnötigerweise eine CPU-Auslastung von 100% bescheren (zumindest auf dem 
Kern, auf dem der Prozess läuft). Was spricht dagegen, die CPU für 
andere Dinge abzugeben, während man wartet. Nichts anderes heißt 
'blocking'.

Ist das Fehlen der Fehlerbehandlung beabsichtigt? Mir ist keine Stelle 
im Manual bekannt, die garantiert, dass der Puffer im Fehlerfall noch 
einen definierten Inhalt hat. Ihn auszuwerten ohne auf Fehler geprüft zu 
haben würde ich daher als Fehler betrachten, mindestens aber als 
schlechten Stil.

[mar IO (Gast)]

Kaj G. schrieb:

memset(&config, 0, sizeof(config));

  config.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | INPCK | ISTRIP | IXON);
  config.c_oflag = 0;
  config.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
  config.c_cflag &= ~(CSIZE | PARENB);

config.c_cflag |= CS8;
config.c_cc[VMIN]  = 1;

  config.c_cc[VTIME] = 0;

Du hast wohl kein Vertrauen in memset()...

[Tobias P. (hubertus)]

Hallo zusammen

ganz vergessen, das hier zu schreiben. Es funktioniert jetzt, eigentlich 
ganz zuverlässig. Ich konnte meine Messgeräte ganz ordentlich ansteuern.

http://www.kooltek.net/programmieren/gpib-unter-linux

Gruss