USB FTDI unter Linux

[adapto (Gast)]

Hallo *,
gibts irgendwo Beispielcode wie man den FTDI unter Linux anspricht?

Dank und Gruss

[adapto (Gast)]

P.s.: In C waere natuerlich am besten...

[Sebastian M. (izaseba)]

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

[adapto (Gast)]

Achso, dann kann ich einfach wie mit einer seriellen Schnittstelle
kommuniziern. Danke.

[Stefan R. (Gast)]

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

[Günter -. (guenter)]

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

[Frank L. (florenzen)]

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

[Günter -. (guenter)]

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?

[Günter -. (guenter)]

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?

[yalu (Gast)]

Wenn ich das richtig in Erinnerung habe, ja.

Schau mal nach, ob du die libftdi benutzen kannst, wenn du vorher den
ftdi_sio rmmodst.

[Frank L. (florenzen)]

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

[Günter -. (guenter)]

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.

[Klaus (Gast)]

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

[Frank L. (florenzen)]

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

[Günter -. (guenter)]

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.

[Bernd K. (Gast)]

ich hab die Erfahrung gemacht das brltty die Kommunikation stoeren kann.

bei debian:
aptitude remove brltty

[Günter -. (guenter)]

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.

[Intra2net Webmaster (Gast)]

Die libFTDI hat ein neues Zuhause:

http://www.intra2net.com/en/developer/libftdi/

Mit git-repositores, Mailinglisten und mehr!

[Stephan Q. (stephanq)]

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

[zwieblum (Gast)]

mach' einen kernel downgrade, das geht am einfachsten.

[... .. (docean)]

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

[Michael G. (linuxgeek)]

Poste mal die Ausgaben aus dem Syslog (tail -f /var/log/messages) wenn 
Du eines dieser Geraete ansteckst.

[Sven K. (Gast)]

Eine Möglichkeit wäre auch ein Problem mit udev.
Würde mal in diese Richtung suchen...

Gruß Sven

[Stephan Q. (stephanq)]

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?

[Stephan Q. (stephanq)]

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.

[Thomas M. (schwuuuuup)]

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

[Michael G. (linuxgeek)]

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?