Important announcement: there is an English version of this forum on
Datum:
Hallo *, gibts irgendwo Beispielcode wie man den FTDI unter Linux anspricht? Dank und Gruss
Datum:
P.s.: In C waere natuerlich am besten...
Datum:
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
Datum:
Achso, dann kann ich einfach wie mit einer seriellen Schnittstelle kommuniziern. Danke.
Datum:
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.)
#include <ftdi.h> #include <stdlib.h> #include <stdio.h> #include <usb.h> #include <ncurses.h> int main(int count, char *argv[]) { int c; initscr(); cbreak(); nodelay(stdscr,TRUE); unsigned char buf [1000]; struct ftdi_context ftdi; int a; int rsize; ftdi_init(&ftdi); ftdi.interface=1; // second FTDI Port ftdi.index=1; ftdi.out_ep=0x83; ftdi.in_ep=0x04; if (ftdi_usb_open(&ftdi, 0x0403, 0x6010) < 0) { printw("Fehler beim Öffnen\n"); exit(1); } else printw ("ftdi_usb_open ok!\n"); printw ("Typ: %d\n", ftdi.type); printw ("usb_read_timeout: %d\n", ftdi.usb_read_timeout); printw ("usb_write_timeout: %d\n", ftdi.usb_write_timeout); printw ("baudrate: %d\n", ftdi.baudrate); printw ("bitbang_enabled: %x\n", ftdi.bitbang_enabled); printw ("bitbang_mode: %x\n", ftdi.bitbang_mode); while(!(c = getch() != ERR) ){ rsize=ftdi_read_data(&ftdi, buf, 1000); if (rsize>0){ for (a=0; a<rsize; a++) printw ("R: %d ", buf[a]); } }; ftdi_usb_close(&ftdi); ftdi_deinit(&ftdi); endwin(); exit (0); } |
Gruß, Stefan
Datum:
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
Datum:
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
Datum:
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:
SYSFS{idVendor}=="0403", SYSFS{idProduct}=="6001", MODE="660", GROUP="dialout"
|
Und die Gruppe wird auch richtig gesetzt, nur nicht die Zugriffsrechte:
crw-r--r-- 1 root dialout 189, 26 2008-09-14 11:49 027 |
Gibt es denn da eine Möglichkeit zu testen ob da noch eine andere Regel mit im Spiel ist die dann die Zugriffsrechte überschreibt?
Datum:
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:
id uid=1000(tux) gid=100(users) groups=16(dialout),33(video),100(users) |
Kann es sein das hier der ftdi_so Treiber in die Quere kommt?
Datum:
Wenn ich das richtig in Erinnerung habe, ja. Schau mal nach, ob du die libftdi benutzen kannst, wenn du vorher den ftdi_sio rmmodst.
Datum:
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
Datum:
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.
Datum:
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
Datum:
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
Datum:
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.
Datum:
ich hab die Erfahrung gemacht das brltty die Kommunikation stoeren kann. bei debian: aptitude remove brltty
Datum:
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:
allow modem user=linux |
Musste ich noch den Resource Manager Daemon neu starten mit:
>sudo /etc/init.d/resmgr restart |
Dann das FT245-Modul noch mal ziehen und wieder stecken und danach konnte ich Daten an /dev/ttyUSB0 schicken.
cat test.txt > /dev/ttyUSB0 |
Ging ohne Fehler.
Datum:
Die libFTDI hat ein neues Zuhause: http://www.intra2net.com/en/developer/libftdi/ Mit git-repositores, Mailinglisten und mehr!
Datum:
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
Datum:
mach' einen kernel downgrade, das geht am einfachsten.
Autor:
... ...
(docean)
Datum:
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
Autor:
Michael G.
(linuxgeek)
Datum:
Poste mal die Ausgaben aus dem Syslog (tail -f /var/log/messages) wenn Du eines dieser Geraete ansteckst.
Datum:
Eine Möglichkeit wäre auch ein Problem mit udev. Würde mal in diese Richtung suchen... Gruß Sven
Datum:
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)
[ 28.935600] apm: BIOS not found. [ 29.118952] ppdev: user-space parallel port driver [ 42.602829] eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX [ 42.602838] eth0: 10/100 speed: disabling TSO [ 42.709905] NET: Registered protocol family 17 [ 98.001157] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 196.656152] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 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?
Datum:
Es läuft wieder. Komischerweise nach
modprobe uhci-hcd |
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.
Datum:
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?
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten