serielle Schnittstellen-Parameter werden durch open() verändert (Linux)

Erwin M. schrieb:
> Woher kommt dieses verdeckte Verstellen der Parameter?

jedes Programm was auf die Serielle Schnittstelle zugreift sollte auch 
die Parameter passend setzen und schon gibt es dein Problem nicht mehr.

Würde ich erst mal schauen, ob der jpnevulator die Parameter absichtlich 
verändert. Eingebauter Default, wenn du den Parameter weg lässt.

Wenn sich in Doku oder Quelltext nichts finden lässt, halt mit strace 
trace=ioctl

Lange Nachtschicht...

Alles mal durchprobieren, was strace beim logger ausgibt.
So was in der Art.

1

#include <fcntl.h>

2

main(int argc, char*argv[]) {

3

  system("stty -a -F /dev/ttyACM0");

4

  fopen("/dev/ttyACM0", "r");

5

  open("/dev/ttyACM0", O_RDONLY);

6

  system("stty -a -F /dev/ttyACM0");

7

}

Aus dem Source von jpnevaluator:

1

static int ttyOpen(char *name,int length) {

2

        int fd;

3

        struct termios options;

4

        fd=open(name,O_RDWR);

5

        if(fd!=-1) {

6

                /* Make sure we send to a raw serial interface! */

7

                fcntl(fd,F_SETFL,0);

8

                tcgetattr(fd,&options);

9

                cfmakeraw(&options);

10

                tcsetattr(fd,TCSANOW,&options);

11

        }

12

        return(fd);

13

}

Der relevante Aufruf ist cfmakeraw (ne alte BSD-Funktion).  Aus dessen 
man-Page:

1

       cfmakeraw()  sets  the terminal to something like the "raw" mode of the

2

       old Version 7 terminal driver: input is available character by  charac‐

3

       ter,  echoing is disabled, and all special processing of terminal input

4

       and output characters is disabled.  The terminal attributes are set  as

5

       follows:

6

7

           termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP

8

                           | INLCR | IGNCR | ICRNL | IXON);

9

           termios_p->c_oflag &= ~OPOST;

10

           termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);

11

           termios_p->c_cflag &= ~(CSIZE | PARENB);

12

           termios_p->c_cflag |= CS8;

Hier geht also deine Parity flöten.  Das einfachste dürfte das Ändern 
vom Source sein.  Alterntiv über LD_PRELOAD ein eigenes cfmakeraw 
reinpatchen.

Au Mist.
Ich hatte so ein Problem schon mal vor ein paar Jahren auf einem 
Suse-System beim sniffen auf der RS232.

Ich erinnere mich leider nicht mehr so recht, was die Ursache war.

Ich muss morgen mal schauen ob ich meine Notizen dazu noch finde. Sorry. 
Heute wird das vermutlich nichts mehr.

Wenn ich mich jetzt so daran erinnere, fällt mir nur ein, dass ich 
ziemlich lange (so 2 Stunden oder so) die man page mit den Parametern 
gelesen habe und einige (hoffentlich) intelligente Veränderungen 
vorgenommen habe.

Tut mir leid. Mehr fällt mir gerade nicht ein.

Ooops. asdfasd hat ja schon in diesem Sinne geantwortet. Sorry.

Erwin M. schrieb:

> Gegen den Workaround eine Sekunde nach dem Programmstart die Parameter
> erneut zu setzen spricht ja nichts, oder?

"Nichts" würde ich nicht sagen. Die Vorgehensweise ist "unsauber", was 
hier ganz klar als "ein Parameter wird gesetzt und dann verändert" 
beschrieben werden kann. Du brätst ja auch kein Schnitzel um unmittelbar 
danach daraus eine Schwarzwälder Kirschtorte zu machen. :-)

Für eine einmalige Sache, würde ich das so lassen. Auf Dauer aber einen 
Sniffer nehmen, der solche "Hacks" überflüssig macht.

> Gegen den Workaround eine Sekunde nach dem Programmstart die Parameter
> erneut zu setzen spricht ja nichts, oder?

Die sinnvolle Methode wäre, den Source so zu ändern, dass nur auf 
raw-Modus umgeschaltet wird und die Leitungsparameter (c_cflag) 
unangetastet bleiben, und dann das als Patch zum Author schicken ...