Hallo Forum, ich habe wie bei FTDI angegeben die libftd2xx.so.1.3.2 und die ... .a in den usr/local/lib/ und den /usr/lib/ Ordner gepackt und danach per make -B die Beispiele gebaut. Nach den beiden Befehlen sudo rmmod ftdi_sio sudo rmmod usbserial dann ausprobiert. Leider scheint es so zu sein, dass die Rechte für diese Zugriffsart nur root überlassen werden. ein "sudo ./read" listet die Infos aus dem angeschlossenen FT232RL auf, während ein "./read" das hier liefert: Library version = 0x10306 Opening port 0 FT_Open(0) failed Die beiden "libftd2xx.so.1.3.2" haben (ich weiß, falscher Weg) ein chmod 777 bekommen. Aber selbst so ist ein Zugriff nur mit "sudo ./read" möglich. Dann habe ich der Lib die Gruppe "dialout" gegeben und dem Programm "read" auch. Leider ändert das auch nichts an dem root-Rechtevorbehalt. Weiß jemand, wie man das Problem lösen kann? OS ist Linux Mint 18.1 in einer Virtualbox VM. Eine andere Zugriffsart per VCP kommt nicht infrage, da es mir um den Direct Access Mode geht, später für einen FT2232 mit höherer Datenrate in synchronem Modus. Danke schonmal.
Änder die 777 für die Libs mal lieber wieder auf 644 ;) Nachdem die Lib im Userspace läuft, braucht sie trotzdem eine Methode, um auf die HW/USB zu kommen. Und das wird wohl das übliche Kernelinterface sein, das auch libusb nutzt. Damit das als non-root geht, braucht es normalerweise wiederum udev-Regeln, die ein "rohes" Device nach dem Anstecken für bestimmte Benutzer explit erlauben. Ungefähr so wie hier: http://robots.mobilerobots.com/wiki/Linux_udev_USB_Device_Permissions_Configuration Allerdings kenne ich jetzt Mint nicht, evtl. gehts da etwas anders.
Nachdem die Version der Biliothek ausgegegen wird, ist es wohl kein Rechteproblem beim Zugriff auf die Bibliothek, sondern auf das Device. dialout betrifft wahrscheinlich nur VCP...
Es würde nahe liegen, dass dein Benutzer einfach keinen ausreichenden Zugriff auf das Gerät hat. Um das dauerhaft zu beheben, kannst du eine udev-Regel für dein Gerät anlegen. So sieht beispielsweise die mitgelieferte udev-Regel eines ST-LINK aus:
1 | /etc/udev/rules.d/49-stlinkv2.rules |
2 | |
3 | # stm32 discovery and evaluation boards, with onboard st/linkv2 |
4 | |
5 | SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE:="0666" |
6 | |
7 | # If you share your linux system with other users, or just don't like the |
8 | # idea of write permission for everybody, you can replace MODE:="0666" with |
9 | # OWNER:="yourusername" to create the device owned by you, or with |
10 | # GROUP:="somegroupname" and mange access using standard unix groups. |
Die Vendor- und Product-ID bekommst du mit "lsusb". Anschließend mit "udevadm control --reload-rules" die Regeln neu laden und das Gerät neu verbinden.
Danke für die Tipps. Rechte der lib zunächst zurückgeändert auf Ursprung (755). Dann die udev-Regel abgeändert auf: SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", MODE :="0660" (habe es aber auch mit SUBSYSTEMS und ATTRS ausprobiert, ebenfalls kein Unterschied) Danach noch mit MODE:="0666". Aber auch keine Wirkung. User wurde der Gruppe dialout hinzugefügt (geprüft in /etc/group, ist vorhanden). Leider geht es weiterhin nicht für Nutzer außer root :-(. Ich probiere das dann gleich mal unter Debian, obwohl LM derzeit meine Wahl Nr. 1 ist... Erstmal danke.
Du musst das Gerät ab- und wieder anstecken, damit die Änderungen wirksam werden.
Ist auch nach jeder Änderung passiert ;-). Soviel ist mir schon bewusst. Aber ich suche mal nach einem Beispiel, in dem ein Skript von der Regel aufgerufen wird. So könnte ich testen, ob die Regel wirklich aufgerufen wird. Test wäre, einen Text in eine Datei schreiben lassen. Nebenbei habe ich auch unter Debian den Zugriff getestet. Aber auch hier geht es nur als root. Leider steht das im FTDI-Dokument auf Seite 6 auch nicht anders .... http://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf Ich glaube, ich muss einen eigenen Treiber schreiben, um diese Rechte-"Lücke" zu überbrücken.
So, die Regel wurde umgeschrieben: SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/home/felix/test.sh" mit test.sh:
1 | #!/bin/sh
|
2 | echo "Hallo" >> /home/felix/test.txt |
bei jedem Dranstecken vom FTDI wird jetzt ein Hallo an test.txt angehängt. Geht zuverlässig wie es scheint. Jetzt noch abgeändert auf: SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0777" (0777 zu Testzwecken!). Geht aber trotzdem nur für root, nicht für andere User :-(
Ruf doch das Testprogramm mal mit strace auf. Da sollte man doch sehen, an welcher Stelle es scheitert...
So, eine Lösung ist diese (wenn auch unschön weil auf einen User festgenagelt): SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", OWNER="felix" Dasselbe mit Group wie hier scheint auch zu laufen (mit felix in der Gruppe "dialout"): SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="dialout" Diese beiden Dinge muss ich unter Linux Mint noch ausprobieren! Damit die eigentlichen VCP-Treiber nicht stören, kann man diese in die Datei /etc/modprobe.d/fbdev-blacklist.conf (debian) /etc/modprobe.d/blacklist.conf (Linux Mint (ausprobiert)) eintragen in der Form: blacklist ftdi_sio blacklist usbserial Achtung: Das hat sicherlich einen Effekt auf alle FTDI-Devices. Eine Mischung aus VCP und D2XX unter Linux geht (wohl) nicht. strace kenne ich noch nicht. Wie nutzt man das? (nur der Ergänzung halber für diesen Beitrag)
Felix Adam schrieb: > strace kenne ich noch nicht. Wie nutzt man das? (nur der Ergänzung > halber für diesen Beitrag) strace <binary> <arguments> Das zeigt alle Systemcalls, deren Parameter und deren Ergebnis an, auch in Bibliotheken. Damit sieht man gerade bei so unklaren Fällen, wann zB. ein Permission Denied zurückkommt oder wo es klemmt (blocking read, ...). Oder an welchen obskuren Orten Konfigurationsfiles etc. gesucht und gefunden werden... Gibt dazu noch ltrace, das auch Bibliothek-Calls ausgibt.
:
Bearbeitet durch User
Das ist klasse, wusste ich bislang nicht. Ich habe außerdem unter Linux Mint weiter getestet, hier lässt sich die udev-Regel aber nicht zur Funktion bewegen :-(. Es gibt zwei rules-Ordner: /etc/udev/rules.d/ (leer) /lib/udev/rules.d/ (viel drin) Egal wo ich meine .rules-Datei ablege, hier passiert einfach nix... Ich probiere mal noch etwas weiter. Scheint aber dann doch auf ein anderes Linux hinaus zu laufen. Doofe Sache.
Die Installation von Linux Mint scheint buggy in Virtualbox. Plötzlich ging sudo nano nicht mehr, weil ich angeblich keine Berechtigung mehr hatte, jetzt ist udevadm weg?!? Ich probiere das mal in einem System außerhalb einer VM und melde mich dann wieder.
Also, es geht auch unter Linux Mint. Die udev-Regel muss so aussehen: ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", OWNER="felix" oder so: ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="dialout" Wenn man dann noch ftdi_sio und usbserial in die Blacklist unter /etc/modprobe.d/blacklist.conf eingetragen hat, dann ist der Zugriff per ftd2xx auch unter Linux Mint (18.1) möglich. Bin happy :-). Danke für den Udev-Rules- und udevadm-Tipp. Der hat viel Zeit gespart. strace kommt jetzt bei der Anwendungsentwicklung sicherlich ab und an zum Zuge.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.