Hallo LUG!
Ich habe folgendes Problem:
Ein per RS232 angeschlossener Thermodrucker soll durch einen Nadeldrucker (Protokolldrucker) abgelöst werden. Die verschiedenen (unwichtigen) Formatierungsfunktionen des Thermodruckers werden durch diverse Steuerzeichen bzw. Zeichen jenseits des ASCII-Standards (Codetabelle unbekannt) ausgegeben. Direkt durchgereicht druckt der Nadeldrucker wild vorsich hin - allerdings nichts, was man lesen könnte.
Da am Ende sowieso nur der Text wichtig ist, soll jetzt alles andere (Steuerzeichen außer LF und alles jenseits ASCII) auf dem Weg von /dev/ttyS0 nach /dev/lp0 rausgeschmissen werden.
Mein selber gebasteltes Bashscript tut dies mit ordentlich CPU-Last dateiweise Zeile für Zeile ganz gut - das äquivalente Perl-Script kommt mit wesentlich weniger CPU-Zeit aus - allerdings auch nur zeilenweise - und genau da liegt das Problem - ich krieg es nicht hin, zeichenweise von /dev/ttyS0 zu lesen UND Zeiträume, in denen nichts kommt, ohne Probleme abzuwarten.
Konkret würde mich interessieren, ob und (wenn ja) wie ich mit Bash und/oder Perl zuverlässig ständig auf Zeichen aus der seriellen Schnittstelle warten und diese entsprechend in "Echtzeit" weiterverarbeiten kann - getc auf /dev/ttyS0 hab ich probiert - das bricht nach ein paar Sekunden Funkstille von sich aus ab ...
Alternaiv interessiert mich alles, was in die Richtung geht, einen Stream auf nichtdruckbare Zeichen zu filtern ...
Mfg, Alexander Tomisch
On Tuesday 06 December 2005 01:18, Alexander Tomisch wrote:
Ein per RS232 angeschlossener Thermodrucker soll durch einen Nadeldrucker (Protokolldrucker) abgelöst werden. Die verschiedenen (unwichtigen) Formatierungsfunktionen des Thermodruckers werden durch diverse Steuerzeichen bzw. Zeichen jenseits des ASCII-Standards (Codetabelle unbekannt) ausgegeben. Direkt durchgereicht druckt der Nadeldrucker wild vorsich hin - allerdings nichts, was man lesen könnte.
Da am Ende sowieso nur der Text wichtig ist, soll jetzt alles andere (Steuerzeichen außer LF und alles jenseits ASCII) auf dem Weg von /dev/ttyS0 nach /dev/lp0 rausgeschmissen werden.
...
Mfg, Alexander Tomisch
Wenn der Stream erst mal auf einem Device ist (a la /dev/ttyS0) kommt nur noch der Kernel an Daten ran. Speziell auf der ttyS* laufen Versuche mit cat / tee / dd .. daneben, weil sie zum Teil die Schnittstelle beeinflussen. Der Weg, erst in ein FiFo zu senden, dieses zu Filtern usw. scheitert meistens daran, das die ausgebenden Programme zur Ausgabe auf ttyS* "voreingestellt" sind. Außerdem werden Steuersignale an die Schnittstelle gesendet, die im FiFo nicht übertragen werden.
Pech ...
(Der beste Weg ist es, den Quellcode des sendenden Programms zu ändern.) (Keine Alternative: 3 Schnittstellen: out1 ->in2 ->(modify)->out3)
Bernhard (Bei Bedarf mehr Informationen. Ich habe mal einen Vortrag über serielle Schnittstelle und deren Programmierung unter Linux gemacht.)
Am Dienstag, den 06.12.2005, 08:34 +0100 schrieb Bernhard Schiffner:
On Tuesday 06 December 2005 01:18, Alexander Tomisch wrote:
Ein per RS232 angeschlossener Thermodrucker soll durch einen Nadeldrucker (Protokolldrucker) abgelöst werden. Die verschiedenen (unwichtigen) Formatierungsfunktionen des Thermodruckers werden durch diverse Steuerzeichen bzw. Zeichen jenseits des ASCII-Standards (Codetabelle unbekannt) ausgegeben. Direkt durchgereicht druckt der Nadeldrucker wild vorsich hin - allerdings nichts, was man lesen könnte.
Da am Ende sowieso nur der Text wichtig ist, soll jetzt alles andere (Steuerzeichen außer LF und alles jenseits ASCII) auf dem Weg von /dev/ttyS0 nach /dev/lp0 rausgeschmissen werden.
...
Mfg, Alexander Tomisch
Wenn der Stream erst mal auf einem Device ist (a la /dev/ttyS0) kommt nur noch der Kernel an Daten ran. Speziell auf der ttyS* laufen Versuche mit cat / tee / dd .. daneben, weil sie zum Teil die Schnittstelle beeinflussen.
Wie sieht die Beeinflussung aus / könnte sie aussehen?
Momentan hab ich noch nicht ganz aufgegeben und experiementiere damit:
cat /dev/ttyS0 | tr -dc "\012 -~"
Sende ich jetzt von einem zweiten Rechner aus einen im raw-Modus des ttys mitgeschnittenen Datensatz (~500B), funktioniert es und alles nicht lesbare fliegt raus - auch wenn ich das zwanzig mal wiederhole. Sende ich eine Datei mit mehreren Datensätzen (größer 4kB), dann bekomm ich nach ~4kB Datensalat. Möglicherweise ein Puffer, der vollläuft? Ist es möglich, diesen zu vergrößern?
Der Weg, erst in ein FiFo zu senden, dieses zu Filtern usw. scheitert meistens daran, das die ausgebenden Programme zur Ausgabe auf ttyS* "voreingestellt" sind.
Inwiefern "voreingestellt"? - wobei ich an einen FiFo noch nicht gedacht habe.
Außerdem werden Steuersignale an die Schnittstelle gesendet, die im FiFo nicht übertragen werden.
Wie gesagt - es geht nur um den Text, der über die Schnittstelle kommt.
Pech ...
Wär dumm, wenn das gar nicht geht ...
(Der beste Weg ist es, den Quellcode des sendenden Programms zu ändern.)
Die Möglichkeit besteht leider nicht.
(Keine Alternative: 3 Schnittstellen: out1 ->in2 ->(modify)->out3)
Wie meinen "Keine Alternative" bzw. was würde es bringen?
Bernhard
(Bei Bedarf mehr Informationen. Ich habe mal einen Vortrag über serielle Schnittstelle und deren Programmierung unter Linux gemacht.)
Sehr gern :)
Alex
Am Dienstag, den 06.12.2005, 12:30 +0000 schrieb Alexander Tomisch:
Am Dienstag, den 06.12.2005, 08:34 +0100 schrieb Bernhard Schiffner:
On Tuesday 06 December 2005 01:18, Alexander Tomisch wrote:
Ein per RS232 angeschlossener Thermodrucker soll durch einen Nadeldrucker (Protokolldrucker) abgelöst werden. Die verschiedenen (unwichtigen) Formatierungsfunktionen des Thermodruckers werden durch diverse Steuerzeichen bzw. Zeichen jenseits des ASCII-Standards (Codetabelle unbekannt) ausgegeben. Direkt durchgereicht druckt der Nadeldrucker wild vorsich hin - allerdings nichts, was man lesen könnte.
Da am Ende sowieso nur der Text wichtig ist, soll jetzt alles andere (Steuerzeichen außer LF und alles jenseits ASCII) auf dem Weg von /dev/ttyS0 nach /dev/lp0 rausgeschmissen werden.
...
Mfg, Alexander Tomisch
Wenn der Stream erst mal auf einem Device ist (a la /dev/ttyS0) kommt nur noch der Kernel an Daten ran. Speziell auf der ttyS* laufen Versuche mit cat / tee / dd .. daneben, weil sie zum Teil die Schnittstelle beeinflussen.
Wie sieht die Beeinflussung aus / könnte sie aussehen?
Momentan hab ich noch nicht ganz aufgegeben und experiementiere damit:
cat /dev/ttyS0 | tr -dc "\012 -~"
Sende ich jetzt von einem zweiten Rechner aus einen im raw-Modus des ttys mitgeschnittenen Datensatz (~500B), funktioniert es und alles nicht lesbare fliegt raus - auch wenn ich das zwanzig mal wiederhole. Sende ich eine Datei mit mehreren Datensätzen (größer 4kB), dann bekomm ich nach ~4kB Datensalat. Möglicherweise ein Puffer, der vollläuft? Ist es möglich, diesen zu vergrößern?
Komisch ist auch, das eine Ausgabeumleitung wie z.B.
cat /dev/ttyS0 | tr -dc "\012 -~" > test.txt
lediglich eine leere Datei anlegt.
Der Weg, erst in ein FiFo zu senden, dieses zu Filtern usw. scheitert meistens daran, das die ausgebenden Programme zur Ausgabe auf ttyS* "voreingestellt" sind.
Inwiefern "voreingestellt"? - wobei ich an einen FiFo noch nicht gedacht habe.
Außerdem werden Steuersignale an die Schnittstelle gesendet, die im FiFo nicht übertragen werden.
Wie gesagt - es geht nur um den Text, der über die Schnittstelle kommt.
Pech ...
Wär dumm, wenn das gar nicht geht ...
(Der beste Weg ist es, den Quellcode des sendenden Programms zu ändern.)
Die Möglichkeit besteht leider nicht.
(Keine Alternative: 3 Schnittstellen: out1 ->in2 ->(modify)->out3)
Wie meinen "Keine Alternative" bzw. was würde es bringen?
Bernhard
(Bei Bedarf mehr Informationen. Ich habe mal einen Vortrag über serielle Schnittstelle und deren Programmierung unter Linux gemacht.)
Sehr gern :)
Alex
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
On Tuesday 06 December 2005 13:30, Alexander Tomisch wrote:
Wenn der Stream erst mal auf einem Device ist (a la /dev/ttyS0) kommt nur noch der Kernel an Daten ran. Speziell auf der ttyS* laufen Versuche mit cat / tee / dd .. daneben, weil sie zum Teil die Schnittstelle beeinflussen.
Wie sieht die Beeinflussung aus / könnte sie aussehen?
Bei einem (cat) kommt beispielsweise das an TxD gesendete auf RxD parallel zurück.
Momentan hab ich noch nicht ganz aufgegeben und experiementiere damit:
cat /dev/ttyS0 | tr -dc "\012 -~"
cat am "normalen" ttyS* scheint bloß bestimmte Zeichen (aus dem 8-Bit-Zeichensatz) mitzubekommen, außerdem kenne ich keine Möglichkeit, so etwas wie ein Puffer-leeren zu organisieren.
Sende ich jetzt von einem zweiten Rechner aus einen im raw-Modus des ttys mitgeschnittenen Datensatz (~500B), funktioniert es und alles nicht lesbare fliegt raus - auch wenn ich das zwanzig mal wiederhole.
Tip: vergleiche die Dateien mal. (s.o.)
Der Weg, erst in ein FiFo zu senden, dieses zu Filtern usw. scheitert meistens daran, das die ausgebenden Programme zur Ausgabe auf ttyS* "voreingestellt" sind.
Inwiefern "voreingestellt"? - wobei ich an einen FiFo noch nicht gedacht habe.
Ausgabe ist auf beliebiges /dev/ttyS* einstellbar, auf /dev/fifo nicht (erfundenener Name, muß mit mknod angelegt werden, erst wenn Empfänger wartet kann Senden erfolgen, Rechte beachten). Probieren!
Außerdem werden Steuersignale an die Schnittstelle gesendet, die im FiFo nicht übertragen werden.
Wie gesagt - es geht nur um den Text, der über die Schnittstelle kommt.
Was aber wenn dein Programm z.B, die Baudrate ändern wollte, und das FiFo würde mit keine Ahnung / Fehler reagieren?
(Keine Alternative: 3 Schnittstellen: out1 ->in2 ->(modify)->out3)
Wie meinen "Keine Alternative" bzw. was würde es bringen?
Drei physische Schnittstellen mit einer Aufgabe beschäftigen.
(Bei Bedarf mehr Informationen. Ich habe mal einen Vortrag über serielle Schnittstelle und deren Programmierung unter Linux gemacht.)
Sehr gern :)
(private Mail folgt)
Alex
Bernhard
Am Dienstag, den 06.12.2005, 14:48 +0100 schrieb Bernhard Schiffner:
On Tuesday 06 December 2005 13:30, Alexander Tomisch wrote:
Wie sieht die Beeinflussung aus / könnte sie aussehen?
Bei einem (cat) kommt beispielsweise das an TxD gesendete auf RxD parallel zurück.
Tatsächlich - wenn der Empfänger cat benutzt, hört der Sender sich selbst ... warum ist dem so?
Momentan hab ich noch nicht ganz aufgegeben und experiementiere damit:
cat /dev/ttyS0 | tr -dc "\012 -~"
cat am "normalen" ttyS* scheint bloß bestimmte Zeichen (aus dem 8-Bit-Zeichensatz) mitzubekommen,
Im RAW-Modus geht alles durch (stty -F /dev/ttyS0 raw) - damit geht auch die in deinem Vortrag angesprochene Übertragung von Binärdateien - allerdings nur bis 4kB - dann kommt wahrscheinlich das cat-Problem von oben zum Tragen.
test.rnd entstammt /dev/urandom und kleiner 4kB
Sender: cat test.rnd > /dev/ttyS0 Empfänger: cat /dev/ttyS0 > test.rnd
MD5 sagt, das die Dateien gleich sind ...
außerdem kenne ich keine Möglichkeit, so etwas wie ein Puffer-leeren zu organisieren.
Das Puffer-leeren passiert - eine minimale Pause zwischen den Datensätzen reicht aus. Interessant wäre es gewesen, den Puffer zu vergrößern - allerdings scheint das direkt im Treiber festgelegt zu werden.
Sende ich jetzt von einem zweiten Rechner aus einen im raw-Modus des ttys mitgeschnittenen Datensatz (~500B), funktioniert es und alles nicht lesbare fliegt raus - auch wenn ich das zwanzig mal wiederhole.
Tip: vergleiche die Dateien mal. (s.o.)
Siehe RAW-Modus - die Daten sind ok - solange nicht mehr als 4kB hintereinander kommen.
Wie meinen "Keine Alternative" bzw. was würde es bringen?
Drei physische Schnittstellen mit einer Aufgabe beschäftigen.
Schon klar, das das Unfug wäre - aber wie würde es funktionieren?
Sehr gern :)
(private Mail folgt)
Danke :)
Bernhard
Alex
Hallo!
Die Tücke liegt im Detail ...
cat /dev/ttyS0 | tr -dc "\012 -~"
gibt mir die zu druckenden Daten auf der aktuellen Konsole aus ...
cat /dev/ttyS0 | tr -dc "\012 -~" > test.txt
wartet immer 4096 Byte ab und schiebt die dann raus.
Gar nicht gut.
Schätze, das ich doch auf C zurückgreifen muss - oder gibt es noch Vorschläge?
Mfg, Alex
Hallo Alexander,
[06.12.05 22:41] Alexander Tomisch schrieb:
Schätze, das ich doch auf C zurückgreifen muss - oder gibt es noch Vorschläge?
Mit stty und/oder setserial läßt sich auch nichts drehen?
Bert
lug-dd@mailman.schlittermann.de
-
Alexander Tomisch -
Bernhard Schiffner -
Bert Lange