Immer dann, wenn man eine COM-Schnittstelle benötigt und man grad keinen Rechner mit einer passenden RS-232-Buchse parat hat, bedient man sich eines USB-COM-Adapters. Diese Dinger sind ja in rauhen Mengen ausgerollt und versehen mehr oder weniger gut ihre Dienste.
In unserem Fall war es nun so, dass wir eine PTT-Steuerung über ein Teamspeak3-Plugin zur Verfügung hatten und ein Funkgerät damit zum Senden bewegen wollten. Nach enthusiastischen Neustarts wegen Nichtfunktionierens kamen die ersten Verteufelungen an das PTT-Gebilde mit der Linux-Hardware, dem USB-Port, dem USB-COM-Adapter, der PTT-Schaltung mit dem Transistor und dem Relais und das alles.
Letztlich hat sich herausgestellt, dass sich der Adapter nach einem warmen Reset des Rechners entweder mal auf den Symlink /dev/ttyUSB0 oder /dev/ttyUSB1 setzte, je nachdem was vorher grad blockiert war und nun frei ist. Wenn dann des kontrollierende Programm fest auf ttyUSB0 eingestellt ist, dann geht es mal oder eben auch mal nicht. Im Microsoft-Dialekt könnte man sagen, der Adapter zieht sich nach einem Neustart des Rechners mal COM3 oder mal COM4.
Abhilfe schafft hier den speziellen Adapter einem festen Symlink zuzuweisen. Dieser neue Port soll – sagen wir mal – /dev/ttyUSB2Serial heißen. Dazu erstellt man im Linux eine Datei (was sonst), die eine neue udev-Regel erzeugt.
Vorweg brauchen wir vom USB-Adapter die Angaben des Herstellers und eine Produktnummer. Die Vendor-ID und die Product-ID bekommt man vom Betriebssystem mit der Abfrage lsusb oder lsusb -v für ganz Schlaue.
user@pc123:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
Bus 001 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
oder
user@pc123:~$ lsusb -v
..
..
idVendor 0x067b Prolific Technology, Inc.
idProduct 0x2303 PL2303 Serial Port / Mobile Action MA-8910P
..
..
In unserem Fall haben wir einen Prolific-Adapter mit der Vendor-ID 067b und der Product-ID 2303 als Device 003 am Bus 001.
Im diesem Verzeichnis wird eine neue Datei angelegt, z.B.: /etc/udev/rules.d/11-usb2serial.rules
Der Inhalt dieser Datei könnte dann folgendermaßen aussehen:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", NAME="ttyUsb2Serial", SYMLINK+="ttyUsb2Serial"
Abspeichern, Neustart des Rechners und testen, ob die neue Schnittstelle vorhanden ist:
user@pc123:~$ ls /dev/ttyU*
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUsb2Serial
Jou, ist da. In meinem Testprogramm kann ich die Schnittstelle aus ansprechen und alle anderen Anwendungen können darauf zugreifen und sie nutzen. Auch nach noch so vielen Neustarts ist die Schnittstelle immer noch verfügbar.
Gefällt mir:
Gefällt mir Wird geladen …
Ähnliche Beiträge
In unserem Fall war es nun so, dass wir eine PTT-Steuerung über ein Teamspeak3-Plugin zur Verfügung hatten und ein Funkgerät damit zum Senden bewegen wollten. Nach enthusiastischen Neustarts wegen Nichtfunktionierens kamen die ersten Verteufelungen an das PTT-Gebilde mit der Linux-Hardware, dem USB-Port, dem USB-COM-Adapter, der PTT-Schaltung mit dem Transistor und dem Relais und das alles.
Letztlich hat sich herausgestellt, dass sich der Adapter nach einem warmen Reset des Rechners entweder mal auf den Symlink /dev/ttyUSB0 oder /dev/ttyUSB1 setzte, je nachdem was vorher grad blockiert war und nun frei ist. Wenn dann des kontrollierende Programm fest auf ttyUSB0 eingestellt ist, dann geht es mal oder eben auch mal nicht. Im Microsoft-Dialekt könnte man sagen, der Adapter zieht sich nach einem Neustart des Rechners mal COM3 oder mal COM4.
Abhilfe schafft hier den speziellen Adapter einem festen Symlink zuzuweisen. Dieser neue Port soll – sagen wir mal – /dev/ttyUSB2Serial heißen. Dazu erstellt man im Linux eine Datei (was sonst), die eine neue udev-Regel erzeugt.
Vorweg brauchen wir vom USB-Adapter die Angaben des Herstellers und eine Produktnummer. Die Vendor-ID und die Product-ID bekommt man vom Betriebssystem mit der Abfrage lsusb oder lsusb -v für ganz Schlaue.
oder
In unserem Fall haben wir einen Prolific-Adapter mit der Vendor-ID 067b und der Product-ID 2303 als Device 003 am Bus 001.
Im diesem Verzeichnis wird eine neue Datei angelegt, z.B.: /etc/udev/rules.d/11-usb2serial.rules
Der Inhalt dieser Datei könnte dann folgendermaßen aussehen:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", NAME="ttyUsb2Serial", SYMLINK+="ttyUsb2Serial"Abspeichern, Neustart des Rechners und testen, ob die neue Schnittstelle vorhanden ist:
Jou, ist da. In meinem Testprogramm kann ich die Schnittstelle aus ansprechen und alle anderen Anwendungen können darauf zugreifen und sie nutzen. Auch nach noch so vielen Neustarts ist die Schnittstelle immer noch verfügbar.
Teilen mit:
Gefällt mir:
Ähnliche Beiträge
admin