Serielle Befehle senden: funktioniert under Windows, jedoch nichtuntre linux

[Adrian B. (adi961)]

Hallo zusammen,

ich habe folgendes Problem.
Ich versuche meinen Projektor per RS-232 ein -und auszuschalten (Sony 
VPL-HW 15). Laut dem communication protocol muss ich eine Baud rate von 
38400 einstellen 1 start-bit 8 data-bits parity auf even und einen 
stop-bit setzten. Aus dem Protokoll ergibt sich dieser HEX-Code 
"a91715000000179a" um den Projektor ein bzw. auszuschalten. (das manual 
ist auch noch mal im Anhang).

Unter Windows funktioniert dies alles einwandfrei. Dort benutze ich das 
Programm HTerm.

Jedoch mit Ubuntu sieht das schon ganz anders aus. Dort bekomme ich den 
Projektor auch nach mehreren Stunden rum probieren nicht eingeschaltet. 
Den serial Adapter habe ich versucht über stty einzustellen und dann die 
Hex-befehle mit "echo "\xa9\x17\x15\x00\x00\x00\x17\x9a" > /dev/ttyUSB0" 
zu verschicken. Irgendetwas scheint dabei nicht zu funktionieren, da ich 
die Shelleingabe erst nachdem ich ich den echo Befehl abgebrochen habe 
(^C) wiederbekomme und am Projektor hat sich auch nichts getan. Ich habe 
auch verschiedene linux Programme benutzt wie cutecom oder GtkTerm.

An einem Berechtigungsproblem sollte es meiner Meinung liegen, da ich 
die Rechte von dem device geändert habe bzw. die Befehle als root 
ausgeführt habe.


Kennt sich jemand mit diesem Problem aus ? oder habe ich etwas völlig 
offensichtliches übersehen ?

Ich hoffe jemand kann mir bei dem Problem helfen.

Beste Grüße Adrian

[g457 (Gast)]

> Igendetwas scheint dabei nicht zu funktionieren, da ich
> die Shelleingabe erst nachdem ich ich den echo Befehl abgebrochen habe
> (^C) wiederbekomme [..]

Hardwareflusskontrolle ausschalten oder den Projekt gefügig machen.

[Timmo H. (masterfx)]

stty -F /dev/ttyUSB0 38400

echo -en '\xa9\x17\x15\x00\x00\x00\x17\x9a'' > /dev/ttyUSB0

[Adrian B. (adi961)]

Danke für die schnellen Antworten, jedoch hat beides nicht geklappt.
Hier hab ich ma die sie stty Einstelligen:

root@ubuntu:/home/parallels/Downloads# stty -F /dev/ttyUSB0 -a
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; 
eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; 
min = 60; time = 1;
parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon 
-ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop 
-echoprt -echoctl -echoke

kann man vierleicht hier einen Fehler erkennen ?

[Georg A. (georga)]

-clocal wäre noch was. Ich hatte aber auch schon das Problem, dass das 
open auf das Device hängt, weil die Daten im Puffer von vorher noch mit 
Flusskontrolle darauf warten, raus zu wollen. Dann muss man open mit 
O_NONBLOCK aufrufen, was in der Shell aber AFAIR nicht geht. Also steck 
den USB-Dongle einfach mal kurz ab...

[Rolf M. (rmagnus)]

Adrian Brennig schrieb:
> An einem Berechtigungsproblem sollte es meiner Meinung liegen, da ich
> die Rechte von dem device geändert habe

Die werden typischerweise von udev automatisch eingestellt.

> bzw. die Befehle als root ausgeführt habe.

Der richtige Weg wäre, den Benutzer, der darauf zugreifen soll, in die 
Gruppe dialout aufzunehmen.

Aber wenn es ein Berechtigungsproblem wäre, käme eine Fehlermeldung, daß 
das Device nicht geöffnet werden kann.

[Ralph S. (jjflash)]

Adrian Brennig schrieb:
> Den serial Adapter

Ich hatte ein Problem mit dem seriellen Adapter !!! Warum auch immer 
funktionierte der Adapter mit PL2303 Chipsatz (von Loglink) nicht !

Mit einem Adapter mit FTDI (von Delock) war alles wunderbar.

Ich schicke stty ein -hupcl mit !

Vielleicht versuchst als Terminalprogramm mal putty ?

[Nils S. (kruemeltee)]

Sollst du wirklich in Hex senden oder nur die Werte in ASCII als Hex 
dargestellt?

Zum versuchen kannst du auch ein Terminal wie picocom, minicom oder 
putty verwernden.

[Adrian B. (adi961)]

Hat leider alles nicht geholfen. Ich möchte nur die Hex-Werte senden.
Ich glaube ich werde mir erst mal nen ordentlichen FTDI Adapter besorgen 
müssen. Mein adapter benutzt den ch341 chip. Nach einiger Recherche 
stellte sich raus, dass es für diesen chip nicht wirklich einen linux 
Treiber gibt.

Ich hoffe, dass es mit einem FTDI Adapter funktioniert.
Und danke für die schnelle Hilfe.

Gruß Adrian

[Jörg W. (dl8dtl) (Moderator)]

Adrian Brennig schrieb:
> Ich möchte nur die Hex-Werte senden.

Je nachdem, was man an der Schnittstelle noch einstellen muss
(eben so Dinge wie flow control), kann man da nicht einfach was mit
einem echo hinsenden.

Entweder ein fertiges Terminalprogramm benutzen (die Hexwerte muss man
dann als Ctrl-Tastenbelegungen tippen), oder ein kleines C-Programm
schreiben, was den gewünschten String sendet, nachdem es zuvor die
Schnittstelle passend konfiguriert hat.

[Adrian B. (adi961)]

Das könnte auch gut sein, denn ich meine mit dem Adapter schon meinen 
Verstärker gesteuert zu haben (mit cr-commands). Nur leider habe ich 
nicht so viel Erfahrung mit seriellen Schnittstellen, deshalb fehlen mir 
da die Ideen wie ich so ein Programm angehen sollte. Ware das auch mit 
einem Skript möglich ?

[Malte S. (maltest)]

Nur der Vollständigkeit halber: hex geht etwas hübscher auch mit

xxd -r -p <<<deadbeef > /dev/whatever

Erspart die \x-orgie bei echo

[Jörg W. (dl8dtl) (Moderator)]

Adrian Brennig schrieb:
> Ware das auch mit einem Skript möglich ?

Nur, wenn die Scriptsprache mit seriellen Schnittstellen umgehen
kann, bspw. pyserial für Python.

[User (Gast)]

kannst ja mal RX und TX zusammenschalten und am Terminalprogramm 
schauen, was da zurück kommt.

[Adrian B. (adi961)]

Ich werd mich mal ein bisschen in python "reinfummelen". Ich habe auch 
al RX und TX zusammengeschlossen und bekam das hier raus (ich habe den 
Receiver einmal auf Hex und einmal auf ASCII gestellt):

CuteCom:

Hex:
00000000: a9 17 15 00 00 00 17 9a

ASCII :
\0xa9\0x17\0x15\0x00\0x00\0x00\0x17\0x9a

echo:

ASCII:
\xa9\x17\x15\x00\x00\x00\x17\x9a


Hex:
00000000: 5c 78 61 39 5c 78 31 37   5c 78 31 35 5c 78 30 30
00000010: 5c 78 30 30 5c 78 30 30   5c 78 31 37 5c 78 39 61
00000020: 0a


Wenn ich den Hex-code mit CuteCom verschicke, bekomme ich genau das 
selbe wieder zurück. Bei echo sieht das schon ganz anders aus. Ich habe 
das selbe auch mal unter windows probiert, da hatte es ja funktioniert, 
und habe dort auch das selbe zurückbekommen, wie bei CuteCom. Nun frage 
ich mich warum es unter Windows funktioniert, jedoch nicht unter linux? 
Ich bekomme ja bei beiden OS-en das selbe zurück.

[Malte S. (maltest)]

Wenn du auf echo bestehst musst du echo -n -e nehmen. Ohne -n fügt echo 
einen Zeilenvorschub an s. 0a am Ende. Ohne -e werden die 
Escapesequenzen nicht interpretiert.

[Adrian B. (adi961)]

ah ok danke, jedoch verstehe ich immer noch nicht warum mein Projektor 
immer noch keine Reaktion zeigt obwohl er das selbe bekommet (mit 
CuteCom) wie mit Windows.

[Malte S. (maltest)]

Dann nochmal einen Schritt zurück die Parameter des seriellen Ports 
checken?
Timingunterschiede? Wird der ganze Block in beiden Fällen in einem 
Rutsch übertragen oder gibt es beim einen oder anderen System Pausen?

[Jörg W. (dl8dtl) (Moderator)]

Malte S. schrieb:
> echo -n -e

Dafür ist dann eigentlich printf gedacht.

[Malte S. (maltest)]

Oder bei reinen Binärdaten zweckmäßigerweise base64, xxd und co. Aber ob 
das das Problem des TE lösen täte? Es sei denn, es gibt doch noch einen 
subtilen Fehler in den Daten.

[Adrian B. (adi961)]

Ich hab jetzt mal nen Python-Script geschrieben:

import time
import serial

ser = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=38400,
    parity=serial.PARITY_EVEN,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    rtscts=False,
    dsrdtr=False,
    writeTimeout=None,
    interCharTimeout=None,
    timeout=None,
    xonxoff=False
)

ser.close()
ser.open()
ser.isOpen()

OFF=bytearray([0xA9,0x17,0x15,0x00,0x00,0x00,0x17,0x9A])

ser.write(OFF)
ser.close()

Hier hab ich wieder das selbe Problem. Auch hier bekomme ich die 
richtigen werte zurück, wenn ich RX und TX Zusammenschließe, jedoch tut 
sich an meinem Projektor immer noch nichts.

[Kaj (Gast)]

Nimm doch einfach hTerm?! gibt's doch auch für Linux...

[Adrian B. (adi961)]

das wollte ich auch schon probierten, jedoch kann ich es nicht unter 
Ubuntu starten (da ich 64bit verwende). Auf der anderen Seite möchte ich 
später das Skript durch eine Hausautomations-Software (openHAB) starten, 
daher wäre hTerm relativ unpraktisch.

[Nils S. (kruemeltee)]

Adrian Brennig schrieb:
> das wollte ich auch schon probierten, jedoch kann ich es nicht unter
> Ubuntu starten (da ich 64bit verwende). Auf der anderen Seite möchte ich
> später das Skript durch eine Hausautomations-Software (openHAB) starten,
> daher wäre hTerm relativ unpraktisch.
32bit multilib