Linux Hochgeschwindigkeits-Zeichenerkennung RS232

Linux Hochgeschwindigkeits-Zeichenerkennung RS232

Ich muss einen Code in C schreiben, um die Zeit zwischen den Zeichen in einer RS232-Zeile unter Linux zu erkennen. Die Zeit zwischen den Zeichen zum Erkennen könnte 1 ms betragen. Ich brauche also etwas, um eingehende Zeichen sehr schnell mit einem Zeitstempel zu versehen. Wenn ich „sehr schnell“ sage, dann meine ich weniger als 1 ms. Das Ziel ist, das Ende eines Frames und den Anfang eines neuen Frames in der Zeile zu erkennen.

Ich verlange keine Codierungslösung, ich möchte nur eine erste Hilfe, um zu wissen, welchen Weg ich einschlagen muss: Ist dies unter Linux möglich? Muss ich einen Treiber ändern, um diese Zeit zu erreichen? Oder kann dies über etwas im Benutzerbereich erfolgen (ich glaube nicht).

Antwort1

Ist das ein integrierter UART oder ein USB-Dongle? Beim ersten würde ich die Interrupt-Routine des seriellen Treibers ändern, um die Daten zusammen mit einem Zeitstempel zu speichern, die Daten mit dem Zeitstempel in den Benutzerbereich zu liefern und den Benutzerbereich das Sortieren zu überlassen. Obwohl Linux nicht in Echtzeit arbeitet, würde ich erwarten, dass es alle Interrupts in weniger als 1 ms beantworten kann, also sollte das ausreichen.

Für einen USB-Dongle usbmonwerden bereits Zeitstempel in Mikrosekunden bereitgestellt, daher gehe ich davon aus, dass man ihn entweder zusammen mit dem normalen seriellen USB-Treiber verwenden oder den seriellen USB-Treiber ändern können sollte, usbmonum diese Zeitstempel zugänglich zu machen.

Antwort2

Ich muss einen Code in C schreiben, um die Zeit zwischen den Zeichen innerhalb einer RS232-Zeile unter Linux zu erkennen ...

Sie haben eineXY-Problem.

Ich möchte das tun, weil eine Stille von mehr als 1 ms das Ende eines Frames und den Beginn eines neuen Frames bedeutet.

(Übrigens, bei asynchroner serieller Kommunikation wie RS-232 ist die uneingeschränkte Nutzung von"rahmen"ist mehrdeutig, da jedes Zeichen gerahmt ist. Wenn ein UART beispielsweise einen „Framing-Fehler“ meldet, ist (möglicherweise) ein Zeichen verloren gegangen. Vermutlich meinen Sie tatsächlich Paket oder Nachrichteneinheit.)

Ihr zusätzlicher Kommentar enthüllt endlich das eigentliche X-Problem, das gelöst werden muss.
Da das eigentliche Problem darin besteht, Lücken zwischen Nachrichten zu erkennen, ist Ihre ursprüngliche Frage zu Y nicht nur schwierig genau in Software umzusetzen, sondern stellt nicht einmal eine praktikable Lösung für das X-Problem dar.

Jede Lösung, die das „Messen“ des Zeitintervalls zwischen empfangenen Zeichen durch Software beinhaltet, um eine Lücke zwischen Nachrichten zu erkennen, ist eine fehlerhafte Lösung. Dieser Ansatz schlägt im entarteten Fall fehl:
Wenn das letzte Zeichen einer Nachricht eintrifft und (für eine Weile) keine weiteren Zeichen vorhanden sind, dann ist diese letzte empfangene Nachrichtins Stocken geratenunbegrenzt, während der Algorithmus auf das nächste Zeichen (das erste Byte der nächsten Nachricht) wartet, damit die Zeitdifferenz berechnet werden kann.
Solange dieses „nächste Zeichen“ nicht empfangen wird, ist das „Ende der Nachricht“ nicht bestimmt und die letzte gültige Nachricht ist abgeschlossen, aber nicht verarbeitet.

Die richtige Lösung besteht darin, Hardware zu verwenden, die messen kann, wann ein Zeichen empfangen wurde bzw. nicht. Einige Atmel USARTs haben eineEmpfänger-TimeoutFunktion zum Erkennen der Lücke zwischen Nachrichten.

Eine mögliche Softwarelösung würde einen (hochauflösenden) periodischen Timer erfordern, den der U(S)ART-Treiber verwenden würde, um die Zeitintervalle zwischen empfangenen Zeichen zu zählen. Bei Verwendung von PIO statt DMA müsste der Treiber die Intervallzählung bei jedem empfangenen Zeichen zurücksetzen. Wenn die Zählung einen Schwellenwert überschreitet (d. h. Zählung * Intervallzeit > Nachrichtenlückenzeit), war der Empfänger zu lange still, was auf eine Nachrichtenlücke hinweist.

verwandte Informationen