meinst Du den FT232BM ?
was willst Du da groß ansprechen?
Kernel mit FTDI Unterstützung kompilieren, Modul laden USB einstecken
und sich über /dev/ttyUSB* freuen.
Gruß Sebastian
Hallo adapto,
du kannst dazu auch die
libftdi
(http://www.intra2net.com/de/produkte/opensource/ftdi/)
nutzen, die seinerseits wieder die libusb nutzt und somit auch komplett
plattformunabhängig ist. Damit hat man gegenüber der simulierten
seriellen Schnittstelle (/dev/ttyUSB) noch mehr Möglichkeiten, z.B. den
Bitbang-Modus zu nutzen.
Ausserdem sollen dann beim ft245 bzw. beim ft2232 im parallel-Modus die
vollen ca. 1MByte/s genutzt werden können (allerdings noch nicht
getestet).
Hier ein kleines C-Testprogrämmchen, dass einfach nur die eingelesenen
Bytes auf dem Schirm als Dezimalzahlen ausgibt (getestet bei mir mit
einem ft2232 im parallel-Modus, der mit einem fpga kommuniziert, für
ft245 oder ft232 musst du den Code evtl. anpassen, sollte aber alles in
der libftdi-Doku stehen.)
Ich wärme hier mal ein altes Thema neu auf.
Wenn ich libftdi unter Linux nutze, dann muss ich ein Programm als su
laufen lassen, damit es Zugriff auf das USB-Gerät erhält. Jetzt greift
ja libftdi und damit libusb nicht über Devices in /dev auf ein USB-Gerät
zu.
Woran liegt es denn jetzt das ein libftdi-basiertes Programm nur als su
Zugriff auf das Device erhält? Oder anders gefragt, gibt es eine
Möglichkeit, dass ich einem normalen Benutzer Zugriff auf das Device
geben kann?
Danke für die Hilfe.
Gruß,
Günter
Zugriffsrechte sind nicht Gottgegeben sondern werden irgendwo festgelegt
;-)
Vermutlich wird die libftdi nicht über ein "sprechendes" Devicefile aka
/dev/ttyUSBn auf das Gerät zugreifen sondern über den entsprechenden
/dev/bus/usb/<BUS>/<DEV> Eintrag. Dieser wird bei jedem Anstecken des
Geräts neu vergeben, du mußt also dafür sorgen, daß direkt hierbei die
Zugriffsrechte korrekt gesetzt werden. Der Service der das macht heißt
zur Zeit udev, das kann sich ggf. aber in ferner Zukunft auch evtl. mal
ändern (Falls der Thread noch mal "aufgewärmt" wird :)). Udev lässt sich
über Regeln ("Udev-Rules") konfigurieren die gerne auch in eigenen
Dateien stehen dürfen. Hier z.B. auf einem Debian System der Eintrag für
einen AVR-Doper:
$ cat /etc/udev/rules.d/obdev.rules
#AVR-Doper
SYSFS{idVendor}=="16c0", SYSFS{idProduct}=="05df", MODE="664",
GROUP="plugdev"
Ist der Doper angesteckt:
$ lsusb -d 16c0:
Bus 002 Device 003: ID 16c0:05df
resultiert daraus:
$ ls -la /dev/bus/usb/002/003
crw-rw-r-- 1 root plugdev 189, 130 2008-09-14 09:11 /dev/bus/usb/002/003
Wie man sieht darf hier nicht jeder Hanswurst sondern nur Mitglieder der
Gruppe Plugdev schreibend darauf zugreifen.
liebe grüße
frank
Danke, das hat schon mal geholfen. Mir war nicht klar das es da noch mal
einen Zweig unter /dev/bus/usb gibt.
Jetzt hab ich eine Regel erstellt die das Device in die dialout Gruppe
legt. Das funktioniert so auch ganz gut, nur wird der MODE-Wert nicht
beachtet.
Meine Regel sieht so aus:
Nochmal ein Nachtrag, trotz das nach meiner obigen Regel die Gruppe
dialout Zugriff auf das Device hat, kann ich das Device nicht mit
libftdi öffnen.
Mit dem id-Befehl habe ich nachgeprüft das mein Benutzer das auch darf:
Oha.
Daß da noch ein extra Kernel-Modul im Spiel ist habe ich nicht gewußt.
Sorry, da dürfte meine Beschriebung oben nur begrenzten Wert haben.
Da kann ich dir leider nicht weiterhelfen.
liebe grüße
frank
Danke erst mal an Alle für die Hilfe.
Der Zugriff von libftdi, bzw. libusb findet tatsächlich über das
/dev/bus/usb/... Device statt.
Es ist eigentlich unerheblich ob der ftdi_sio-Treiber geladen ist oder
nicht. Sobald ich die Zugriffsrechte für das /dev/bus/usb/... Device
richtig gesetzt hatte, konnte ich darauf zugreifen. Dazu muss ich aber
sagen, das ich das für den Versuch ganz gemein mit chmod gemacht hatte.
Das funktioniert also nur für diese Situation. Sobald das Gerät gezogen
und wieder gesteckt wird geht es nicht mehr.
Das Problem scheint nur zu sein, dadurch das der ftdi_sio-Treiber
geladen wird, kann ich nicht die Zugriffsrechte für den /dev/bus/usb/...
Eintrag über udev-Regeln setzten. Zwar konnte ich die Gruppe über die
udev-Regel ändern, aber der MODE-Befehl meiner Regel wurde nicht
übernommen.
Ich vermute das die Lösung darin besteht sicherzustellen das für das
Device nicht der ftdi_sio-Treiber geladen wird. Dann hoffe ich das mein
MODE-Befehl in der udev-Regel angewendet wird.
Hallo,
Ich habe die Erfahung gemacht das die libftdi bei sehr hohen
Geschwindigkeiten nicht mehr richtig funktioniert, nur der
Kernel Treiber funktioniert einwandfrei!
Mann muss hier nur die Latenzzeit umstellen.
Wenn Du die libftdi verwenden willst darf das Kernel
Modul nicht geladen sein, wenn Du als root eingelogt
bist dann kann die libftdi den Kernel Treiber automatisch
entladen. Das geht aber nur als root!
Bei jeden anstecken der Hardware wird das Kernel Modul
neu geladen.
Du mussten das Modul in der "blacklist ??" eintragen
damit es nicht mehr geladen wird.
Gruß
Klaus
Hallo Günter,
ich habe mich noch einmal mit der Sache beschäftigt und festgestellt,
das ich wieder einmal von falschen Annahmen ausgegangen bin. Als du das
ftdi_sio Modul ins Spiel gebracht hast dachte ich das gehört zur libftdi
und soll an den bestehenden Modulen vorbei irgendeinen Zugriff
realisieren (NVidia ist für solcherlei Dinge bekannt). Mittlerweile habe
ich festgestellt daß ftdi_sio ganz regulär zum Kernel gehört und nur ein
Aufsatz zu usbserial ist. Ich bitte mir nachzusehen daß ich nicht zu
jeder Zeit alle Linux Kernelinterna auswendig kenne.
Ich habe mich ferner daran erinnert Besitzer einer bestückten Platine
mit FT232RL zu sein und habe diese mal an den Rechner gesteckt. Das
Verhalten, nachdem ich eine udev-Rule erstellt hatte, ist ganz genau das
von mir oben beschriebene und das ftdi_sio Modul ist auch geladen, daran
kann es also nicht liegen. Bei mir tut udev exakt wie ihm aufgetragen
wurde.
Ich vermute dein Problem also nicht beim Kernel-Modul ftdi_sio sondern
eher darin das der udevd nicht so will wie du. Warum das so ist kann ich
dir aber beim besten Willen nicht sagen. Versuche mal ein wenig mit MODE
und GROUP herumzuspielen und drehe bitte mal das Logging hoch:
# udevcontrol log_priority=debug
sollte den udevd etwas gesprächiger machen.
Vielleicht findest du im Debug-Output etwas was dich weiterbringt.
Zu dem was Klaus gesagt hat kann ich nichts kommentieren, da habe ich
keine Erfahrung damit.
liebe grüße
frank
Danke noch mal für alle Hinweise.
Ich hab ein wenig auf den openSUSE Maillisten nachgefragt, erst
[opensuse] und dann [opensuse-security], wo ich auch heute eine
hilfreiche Antwort erhalten habe. Die Idee ist nicht durch udev-Regeln
den Zugriff auf Hardware für Benutzer zu gewähren, sondern über einen
Resourcenmanager.
Den folgenden Link hab ich zur Information erhalten:
http://forgeftp.novell.com/resmgr/web/#id2830544
Jetzt werde ich mich mal mit der Konfiguration auseinander setzten und
sehen ob ich darüber einen Zugriff erhalte.
Also das hat funktioniert. Nachdem ich eine neue Datei '50-modem.conf'
im Pfad /etc/resmgr.conf.d erzeugt habe und darin meinen Benutzername
'linux' eingetragen habe:
1
allowmodemuser=linux
Musste ich noch den Resource Manager Daemon neu starten mit:
1
>sudo/etc/init.d/resmgrrestart
Dann das FT245-Modul noch mal ziehen und wieder stecken und danach
konnte ich Daten an /dev/ttyUSB0 schicken.
Hallo an alle!
Ich bin neu hier im Forum und dringend auf der Suche nach einer Lösung
meines Problems. Leider konnte ich nach stundenlangem Suchen keine
Antwort finden. Ferner hoffe ich, dass ich in diesem Thread richtig bin.
Es geht um folgendes:
Basierend auf FTDI-Chips verwende ich zwei USB-seriell-Konverter und ein
USB/GPIB Interface von Prologix (ebenfalls FTDI basiert), um diverse
Messgeräte auszulesen. Als Betriebssystem nutze ich derzeit Linux Mint 6
(Ubuntu) mit der Kernelversion 2.6.27-7-generic. Der Aufbau
funktionierte einwandfrei, bis ich heute morgen ein Systemupdate
durchführte. Seitdem werden alle Adapter NICHT mehr als /dev/ttyUSB*
erkannt, was jedoch vorher der Fall war. Hat irgendjemand dieselben
Erfahrungen gemacht und weiß eine Lösung dazu? Die libftdi ist
installiert, ebenso die libusb.Die Module ftdi_sio und usbserial wurden
geladen. Die einzige Ursache, die mir nach stundenlanger Sucherei
sinnvoll erscheint, ist, dass die UART detection nicht aktiv ist. Hierzu
auch folgender Link:
[http://patchwork.kernel.org/patch/10236/]
Allerdings weiß ich mit dem Patch (noch) nichts anzufangen, da ich nicht
weiß, wie er anzuwenden ist (zu neu in Linux).
Hat irgendjemand Vorschläge, oder kann mir helfen? Bin für jeden
Ratschlag dankbar.
Viele Grüße,
Stephan
Stephan Quint schrieb:
> Hat irgendjemand Vorschläge, oder kann mir helfen? Bin für jeden> Ratschlag dankbar.
Vlt hilft auch:
>ich hab die Erfahrung gemacht das brltty die Kommunikation stoeren kann.>bei debian:>aptitude remove brltty
Hallo allerseits, vielen Dank für die Hilfestellungen.
1) Ich habe nun verschiedene Kernelversionen getestet 2.6.27-7,
2.6.27-9, 2.6.27-11, 2.6.27-14. Auch mit einer älteren Version 2.6.25-2
funktioniert es nicht.
2) An brltty hat es auch nicht gelegen, auch nach Entladen des Moduls
wurde nichts erkannt.
3) nach 3-maligen Ein- und Ausstecken des Adapters liefert mir dmesg
folgendes: (nur mit Kernel 2.6.25-2)
1
[ 28.935600] apm: BIOS not found.
2
[ 29.118952] ppdev: user-space parallel port driver
3
[ 42.602829] eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
4
[ 42.602838] eth0: 10/100 speed: disabling TSO
5
[ 42.709905] NET: Registered protocol family 17
6
[ 98.001157] hub 1-0:1.0: unable to enumerate USB device on port 2
7
[ 196.656152] hub 1-0:1.0: unable to enumerate USB device on port 2
8
[ 207.248930] hub 1-0:1.0: unable to enumerate USB device on port 2
'tail -f /var/log/messages' liefert nach Ein-und Ausstecken nichts
neues, d.h. es wird nichts geloggt.
@ Sven: Hast du irgendetwas spezielles im Sinn?
Das gleiche hab ich bereits mit den neueren Kernelversionen versucht,
hat jedoch nicht geklappt. Nach Reinstallation von Kernel 2.6.25-2 und
obigem Befehel geht es also. Komischerweise hab ich das Modul auch nicht
manuell entfernt oder sonstwas.
Ich hab ehrlich gesagt keine Ahnung, was da vor sich geht/ging.
Immerhin läufts.
Vielen Dank an euch.
Hi,
ich weiß, der Thread ist Ur-Alt, aber er steht bei Google noch ganz
oben, daher will ich hier mal einen kleinen Hinweis hinterlassen, der
mir sehr geholfen hätte:
KABEL!
Ich habe hier allein zwei ganz normalausehende und sonst auch
funktionsfähige USB-Kabel, mit denen ich jedes Mal die meldung bekomme
unable to enumerate USB device on port 1
Nehme ich ein anderes (ein wenig dickeres, besser abgeschirmtes?) Kabel,
wird der FTDI-Chip erkannt!
Schönen Gruß
TOM
Schittebön mien Herr, ist allerdings mit HW-Flusskontrolle. Alles andere
hat sich als unbrauchbar erwiesen. Und auf Controllerseite musst Du das
natürlich auch berücksichtigen. Die Implementierung basiert auf
libftdi/libusb und benötigt den VCP-Treiber daher nicht (sowieso von
wenig praktischen Nutzen ausser für Adapter), es stört aber nicht wenn
er dennoch geladen wird.
Greets,
Michael
P.S. Zefix schon wieder eine Leichenschändung. Früher gab es hier mal
eine rote Warnung, wo ist die geblieben?