Linux serielle Schnittstelle buffer nicht leer beim öffnen Gerät

Ich habe ein system wo ich da ein merkwürdiges Verhalten mit der seriellen ports dass ich nicht erwarten. Ich habe vorher gesehen das bei Gelegenheit mit usb-zu-Seriell-Adapter, aber ich bin jetzt sehen, es auf native serial-ports als auch mit viel größerer Häufigkeit.

Das system eingerichtet ist, führen Sie automatisierte tests und führen Sie zunächst einige Aufgaben, die zu einer großen Menge an Daten, die ausgegeben werden von der seriellen Gerät, während ich nicht die ports öffnen. Das Gerät wird auch zurückgesetzt. Nur die tx/rx-Leitungen verbunden sind. Es gibt keine flow-control.

Nachdem diese Aufgaben abgeschlossen sind, die testware öffnet den seriellen Port und sofort schlägt fehl, da bekommt er unerwartete Antworten. Wenn ich Schreibe das, fand ich, dass wenn ich öffnen Sie die serielle Schnittstelle in einem terminal-Programm, ich sehe einige Kilobyte der alten Daten (die wird angezeigt, gesendet wurden, wenn der port geschlossen wurde) sofort gespült. Sobald ich in der Nähe dieses Programm kann ich dann die tests ausführen wie erwartet.

Was könnte dies geschehen? Wie funktioniert Linux behandeln die Pufferung der seriellen Schnittstelle, wenn das Gerät geschlossen ist? Wenn ich ein Gerät neu geöffnet, machte ihn zu senden, und dann wird es geschlossen ohne zu Lesen, würde dies dazu führen, die gleichen problem?

InformationsquelleAutor djs | 2011-11-10
  1. 4

    Dem Linux-terminal-Treiber-Puffer-Eingangs, auch wenn es nicht geöffnet ist. Dies kann ein nützliches feature, vor allem, wenn die Geschwindigkeit/Parität/etc. entsprechend festgelegt sind.

    Repliziert das Verhalten der kleinere Betriebssysteme, Lesen Sie alle ausstehenden Eingang vom Hafen, sobald es geöffnet ist:

    ...
int fd = open ("/dev/ttyS0", O_RDWR | O_NOCTTY | O_SYNC);
if (fd < 0)
        exit (1);

set_blocking (fd, 0);   //disable reads blocked when no input ready

char buf [10000];
int n;
do {
        n = read (fd, buf, sizeof buf);
} while (n > 0);

set_blocking (fd, 1);  //enable read blocking (if desired)

...  //now there is no pending input



void set_blocking (int fd, int should_block)
{
        struct termios tty;
        memset (&tty, 0, sizeof tty);
        if (tcgetattr (fd, &tty) != 0)
        {
                error ("error %d getting term settings set_blocking", errno);
                return;
        }

        tty.c_cc[VMIN]  = should_block ? 1 : 0;
        tty.c_cc[VTIME] = should_block ? 5 : 0; //0.5 seconds read timeout

        if (tcsetattr (fd, TCSANOW, &tty) != 0)
                error ("error setting term %sblocking", should_block ? "" : "no");
}
    • Ich dachte, dass könnte der Fall sein. Also, warum sehe ich nur dieses Verhalten Teil der Zeit? Ich bin mit pyserial für den test und die enthaltenen miniterm.py Skript als ein interaktives terminal. Es ist nicht nur ein serieller port, der das problem hat. Es scheint zu wechseln. Alle Serien Häfen eingehenden Daten, wenn Sie geschlossen sind, aber nur einer wird am Ende mit ihm gepuffert an dem Punkt, wenn ich es öffne. Vielleicht ist die Baudrate wird nur Links richtig gesetzt auf die?
    • Port-Geschwindigkeit ist die erste Sache, die kommt in den Sinn für mich. Es könnte auch sein, dass gpsd oder logind ist der Zugriff auf geschlossene ports sind auf der Suche für ein GPS-Gerät oder login-Verbindung und ändert die port-Geschwindigkeit spekulativ.
    • Keiner dieser Dienste ausgeführt werden. stty gemeldet, die alle ports auf 115200 Recht vor, überprüfte ich und fand nur eine von Ihnen hielt die Puffer. Ist dies das richtige tool zu verwenden, um überprüfen Sie die baudrate?
    • ist das was ich schon immer verwendet und hatte nie ein problem.
    • hast du die Dinge reibungslos läuft?
    • Ich habe noch keine gute Erklärung, warum ich normalerweise nicht sehen, dieses Verhalten auf serielle ports. Ich hab eingestellt das test-framework zu deaktivieren Sie den Puffer zu starten, was das problem löst, wenn nicht meine Neugier...

    InformationsquelleAutor wallyk
Schreibe einen Kommentar