Hi, ich habe hier ein USB-Gerät, welches als COMx bzw. /dev/ttyUSBx im System auftaucht, mit dem ich Daten austauschen will. Allerdings soll das jetzt NICHT mittels Dateifunktionen über den Schnittstellennamen geschehen, sondern auf Basis der VID und PID des Gerätes. Nur: wie geht das? Gibt es irgendwo brauchbare Beispielcodes für Windows und Linux, welche 1. das Ermitteln und Öffnen des richtigen USB-Gerätes und 2. den Datentransfer zu und vom Device zeigen? Danke!
Satz K. schrieb: > Allerdings soll das jetzt NICHT mittels Dateifunktionen über den > Schnittstellennamen geschehen, sondern auf Basis der VID und PID des > Gerätes. Was soll das? Wie es geht, kannst Du den Devicetreiberquellen entnehmen, die für Linux verfügbar sind. Um so etwas mit Windows umzusetzen, musst Du entweder libusb-win32 oder WinUsb (http://msdn.microsoft.com/en-us/library/windows/hardware/ff540196%28v=vs.85%29.aspx) verwenden. Nur: Was soll das? Das ist Unfug, denn das, was Du selber machen möchtest(?), ist genau das, was der zigtausendmal getestete Devicetreiber auch macht.
> [..] NICHT [..] über den Schnittstellennamen geschehen, sondern auf > Basis der VID und PID des Gerätes. Falls es um die ein-eindeutige Identifizierung des Geräts geht: Udev ist Dein Freund (zumindest unter Linux). Ansonsten libusb. Aber das würde ich mir gaanz schwer überlegen ob das wirklich sinnvoll ist für ne Uart.
Ich habe das unter Linux mal über Libusb gemacht. Da muss mal allerdings wissen, wie genau die interne Kommunkation stattfindet (bulk, isochron etc..) Unter Windows ist es noch etwas schwieriger, weil man sich mit den internen Device-Treibern noch rumärgern muss. Ich würde eine Einarbeitung in Libusb empfehlen, ist aber keine Sache von 5 Minuten.
Satz K. schrieb: > Hi, > > ich habe hier ein USB-Gerät, welches als COMx bzw. /dev/ttyUSBx im > System auftaucht, mit dem ich Daten austauschen will. > > Allerdings soll das jetzt NICHT mittels Dateifunktionen über den > Schnittstellennamen geschehen, sondern auf Basis der VID und PID des > Gerätes. > > Nur: wie geht das? Gibt es irgendwo brauchbare Beispielcodes für Windows > und Linux, welche 1. das Ermitteln und Öffnen des richtigen USB-Gerätes > und 2. den Datentransfer zu und vom Device zeigen? > > Danke! https://github.com/makerbot/pyserial/blob/master/serial/tools/list_ports_posix.py https://github.com/makerbot/pyserial/blob/master/serial/tools/list_ports_windows.py Das sollte sich in anderen Sprachen nachbauen lassen
Rufus Τ. Firefly schrieb: > Nur: Was soll das? > > Das ist Unfug, denn das, was Du selber machen möchtest(?), ist genau > das, was der zigtausendmal getestete Devicetreiber auch macht. Es ist kein Unfug und mit ein wenig nachdenken erschließt sich der Grund auch: Das Gerät soll auf Anhieb eindeutig identifiziert werden. Im Detail: es gibt keine Möglichkeit, dass der Benutzer es vor Verwendung konfiguriert, es gibt also keine Vorgabe, an welchem COMx / ttyUSBx das Gerät angeschlossen ist. Man könnte also a) sämtliche seriellen Schnittstellen der Reihe nach öffnen, irgend was dort hinschicken und auf die korrekte Antwort warten (und unter Umständen ungewollte Aktionen an anderen Geräten verursachen) -> Murks oder b) das Gerät auf Anhieb eindeutig an Hand von VID und PID identifizieren.
Satz K. schrieb: > b) das Gerät auf Anhieb eindeutig an Hand von VID und PID > identifizieren. Das klappt zumindest unter Windows auch. Und zwar lässt sich das alles vor dem Öffnenn über die Registry herausfinden. Bei FTDI hab ich das schon mehrfach gemacht (gibts auch in der Knowledge Base da) und bei den anderen Verdächtigen klappt das ganz sicher ähnlich. Klar,über LibUSB geht das auch, da musst du aber erst mal herausfinden, wie genau der jeweilige USB-Serial Controller die Daten haben will, um das mit der LibUSB nachzubauen. Sicherer ist es, über die Systemfunktione (Registry, UDEV...) das Gerät eineindeutig zu ermitteln.
Satz K. schrieb: > Es ist kein Unfug und mit ein wenig nachdenken erschließt sich der Grund > auch: Das Gerät soll auf Anhieb eindeutig identifiziert werden. Im > Detail: es gibt keine Möglichkeit, dass der Benutzer es vor Verwendung > konfiguriert, es gibt also keine Vorgabe, an welchem COMx / ttyUSBx das > Gerät angeschlossen ist. Das ist aber eine völlig andere Aufgabenstellung. Dazu ist es überhaupt nicht erforderlich, Dinge zu erledigen, die der Devicetreiber erledigt, dazu muss lediglich die Zuordnung des Gerätes (das übrigens durch VID/PID nicht eineindeutig definiert ist) zur verwendeten virtuellen Schnittstelle bestimmt werden. Und das ist 'ne komplett andere Baustelle, dazu muss der USB-Devicetree beim Betriebssystem abgefragt werden. Unter Windows ist das mit ein paar wohlinformierten Registry-Zugriffen erledigt. Wie das unter Linux funktioniert, wird Dir aber jemand anderes erklären müssen.
> b) das Gerät auf Anhieb eindeutig an Hand von VID und PID > identifizieren. Es ist doch Unfug, denn VID/PID ist nicht eindeutig. Nimm sowas wie die Seriennummer [0] dazu, erzeug per udev ein-eindeutige Gerätenamen wie /dev/tty-meine-lieblings-uart und /dev/tty-meine-andere-uart und sei glücklich. Windoofs macht das übrigens schon mehr oder weniger selbständig, zumindest pro Maschine ist die Zuordnung persistent. [0] Bei vernünftigen(tm) [1] Tschipps kann man sich die nach belieben setzen [1] namentliche z.B. FT232 (und andere von FTDI) und cp210x (und andere von Silabs)
Rufus Τ. Firefly schrieb: > (das übrigens durch VID/PID nicht eineindeutig definiert ist) Was ist daran nicht eindeutig? Die Wahrscheinlichkeit, dass zufällig ein anderes Gerät mit - gleicher VID - gleicher PID und - gleicher Funktionalität (USB CDC) vorhanden ist, dürfte gegen Null gehen.
Unter Windows kannst du über die setupapi alles über dein Device herausfinden. Aber wie willst du verhindern, das ein anderes Programm den Port öffnet und deinem Gerät Unsinn schickt ?
Satz K. schrieb: > Die Wahrscheinlichkeit, dass zufällig ein > anderes Gerät mit > > - gleicher VID > - gleicher PID > und > - gleicher Funktionalität (USB CDC) > > vorhanden ist, dürfte gegen Null gehen. Nö. Dazu musst Du nur zwei gleichartige Geräte gleichzeitig nutzen. Das ist eine gar nicht so ungewöhnliche Konstellation. Eineindeutig werden solche Geräte durch eine Seriennummer, die im Devicedescriptor untergebracht werden kann. Wenn man die Firmware des USB-CDC-Gerätes selbst baut (per V-USB oder mit dem USB-Stack eines µCs) ist das auch kein größeres Problem. Macht man das nicht, ist das Gerät, wenn es an einem anderen USB-Port angeschlossen wird, für Windows ein neues Gerät, was wieder eine neue virtuelle serielle Schnittstelle zur Folge hat etc. Bei Geräten ohne Seriennummer ist die Zuordnung an die Kombination aus Gerät und Position im physikalischen USB-Baum gebunden.
Satz K. schrieb: > Die Wahrscheinlichkeit, dass zufällig ein > anderes Gerät mit > > - gleicher VID > - gleicher PID > und > - gleicher Funktionalität (USB CDC) > > vorhanden ist, dürfte gegen Null gehen. Es ist auch eher unwahrscheinlich das in dem selben Haus, in der selben Strasse, in der selben Stadt, zwei Personen mit dem exakt gleichen Namen wohnen. Und trotzdem passiert das gar nicht so selten. Satz K. schrieb: > b) das Gerät auf Anhieb eindeutig an Hand von VID und PID identifizieren. VID/PID sind aber eben nicht eindeutig. Eine MAC-Adresse ist auch nicht eindeutig, auch wenn das manch einer gerne haette. Wie willst du etwas eindeutig Identifizieren, wenn du etwas nicht eindeutiges als referenz nimmst?
Satz K. schrieb: > Was ist daran nicht eindeutig? Die Wahrscheinlichkeit, dass zufällig ein > anderes Gerät mit > > - gleicher VID > - gleicher PID > und > - gleicher Funktionalität (USB CDC) > > vorhanden ist, dürfte gegen Null gehen. Gerade bei CDC nehmen Geräte- oder Adapterkabelhersteller gerne fertige Chipsets, die manchmal nicht einmal individuelle Seriennummern enthalten. Da kannst du mit VID/PID oder sogar mit VID/PID/Seriennr. gar nichts anfangen.
Satz K. schrieb: > Die Wahrscheinlichkeit, dass zufällig ein > anderes Gerät mit > > - gleicher VID > - gleicher PID > und > - gleicher Funktionalität (USB CDC) > > vorhanden ist, dürfte gegen Null gehen. Es ist schon schlimm, wenn man als (angeblicher) Programmierer sich keinen anderen Anwendungsfall als grade den eigenen vorstellen kann - man braucht nur etwa 2 gleiche Messwerterfassungssystem anzuschliessen, weil die Kanalzahl sonst nicht reicht. Oder Relaiskarten... Genauso könntest du argumentieren, die Wahrscheinlichkeit von 2 Monitoren an einem PC wäre null, bloss weil du sowas selber nicht hast. Fehlende Phantasie ist äusserst kontraproduktiv. Gruss Reinhard
Schau unter Linux mal in Ordner "/dev/serial/by-id/" ;-)
Satz K. schrieb: > Was ist daran nicht eindeutig? Die Wahrscheinlichkeit, dass zufällig ein > anderes Gerät mit > > - gleicher VID > - gleicher PID > und > - gleicher Funktionalität (USB CDC) > > vorhanden ist, dürfte gegen Null gehen. Hä? Ich hab an meinem Rechner auf Arbeit manchmal 5 oder 6 solche FTDI Serial Kabel hängen und alle haben die gleiche VID/PID und unterscheiden sich zum Glück im Serial Number Descriptor. Damit kriegt Windows eine konstante Zuordnung der COM Ports zum Kabel problemlos hin. Auch mehrere Xilinx Programmer Kabel und/oder Eval-Boards hab ich da manchmal angesteckt, auch unsere eigene Hardware mit USB steckt meist 3 oder 4 mal am PC. Blöde wirds, wenn kein eineindeutiger Serial Number Descriptor gespeichert ist, hatte ich mal bei USB-RS422 Umsetzern mit Silabs Chip. Da musste man dann mit dem Tool von Silabs erst mal Seriennummern vergeben und dann hats auch geklappt, denn zu allem Überfluss hatte der Windows 7 Treiber auch noch Probleme damit, die Kabel auseinander zu halten. Also hol dir lieber die Zuordnung aus dem OS, dann hast du was sinnvolles und keine Frickellösung.
Reinhard Kern schrieb: > Fehlende Phantasie ist äusserst kontraproduktiv. Laberrhabarber. Ich lege sowohl VID als auch PID selber fest. Ich lege das Protokoll selber fest. Und ich weiß deswegen, dass es nichts macht, wenn jemand mehrere dieser Geräte gleichzeitig anschließt. Und wenn wirklich jemand meine VID und PID klaut, dann beherrscht er immer noch nicht das Protokoll, da es sich eben NICHT um ein primitives USB/seriell-Gerät handelt. Aber trotzdem danke für den Klugschiss, der mich bei meinem Problem null weiterbringt :-( (Und jetzt bitte keine Kommentare dazu, dass ich die VID nciht selber "festlegen" kann, ich weiß es...)
Sag das doch gleich. Bei Custom Protokoll und Custom Device Classes ist dann absolut üblich, über LibUSB, WinUSB oder ähnliches zu gehen. Von deinem Erstposting konnte man das nicht erkennen, das klang so nach FTDI und Co.
Satz K. schrieb: > Ich lege das Protokoll selber fest. Wohl nicht, sonst würde das Gerät ja nicht als serielle Schnittstelle angesprochen werden. Du nutzt also eine Standarddeviceklasse; sonst wäre ja der ganze von Dir angedachte Aufriss (auch wenn er unnötig ist) Dir gar nicht eingefallen.
Rufus Τ. Firefly schrieb: > Satz K. schrieb: >> Ich lege das Protokoll selber fest. > > Wohl nicht Hallo was ist das für ein Quatsch? Über eine serielle Schnittstelle kann ich beliebige Daten rüberschieben, die kann ich beliebig organisieren und mir folglich das Kommunikationsprotokoll mit der anderen Seite selbst festlegen. Warum sollte das - nur weil die Daten jetzt über ein USB-Gerät, welches so tut, als wäre es eine serielle Schnittstelle - nicht mehr so sein?
Dein serielles Protokoll hat aber überhaupt nichts mit USB zu tun und über USB reden wir doch die ganze Zeit ...
:
Bearbeitet durch User
Hans-Georg Lehnard schrieb: > Dein serielles Protokoll hat aber überhaupt nichts mit USB zu tun und > über USB reden wir doch die ganze Zeit ... Das ist wohl auch die Ursache des Missverständnisses. @TO: Wenn Du eine USB-CDC benutzt dann passiert da eine ganze Menge innerhalb des USB Stacks um DEINE Daten zu transferieren. Um die USB-CDC aber mit dem Betriebssystem "spielen" zu lassen, muss Deine Device sich aber auf "USB-Ebene" an das notwendige Protokoll halten. Was da in DEINEN Daten drinsteht ist dem USB Stack völlig egal. DIESE Daten sind das, was Du immer als Protokoll bezeichnest. Ich hoffe, der Unterschied ist jetzt etwas klarer. Grüße Andreas
Andreas H. schrieb: > Das ist wohl auch die Ursache des Missverständnisses. Da läuft noch ein anderer Thread von Herrn Satz K. (satz_k). Er ist schnell mit den Worten, aber mit dem Lesen (z.B. der Doku, dem WIKI Eintrag oder sonstwas über USB) eher weniger. Satz K. schrieb: > Aber trotzdem danke für den Klugschiss, der mich bei meinem Problem null > weiterbringt :-( Und frech isser. Ob ihn das weiterbringt?
Um mit Linux irgendwelche Infos über das System zu bekommen, kann man die Ordner /sys und /proc verwenden: /sys/bus/usb/devices/busnummer[.hubnummer*].devicenummer:gerätkonfigurat ion.interface Ist auch saupraktisch, um Informationen für udev-Regeln zu finden, wenn du welche erstellen möchtest. oder /proc/bus/input/devices Im dem Ordner finde ich gerade weniger Info, die du gebrauchen könntest. Beide beinhalten Textdokumente mit den Geräteinformationen. http://www.linux-usb.org/FAQ.html bietet ein paar mehr Infos. Für die Kommandozeile gibts usb-devices und lsusb.
Klaus schrieb: > Und frech isser. Ob ihn das weiterbringt? Naja, wenn keiner mehr mit ihm "spielen" will, dann sicher nicht. Das merkt er dann ja schon. Bloss dann wird es wirklich schwierig. Mein "Favorit" ist ja momentan Ramones in Beitrag "Blick's mit dem Timer nicht :(" Vielleicht gabs ja dieses Jahr zu Weihnachten neben dem uP Starterkit auch noch mal ein Glas Weihnachtsglühwein. Und das teigt den Jungs zu Kopfe^^ Grüße Andreas
Simon S. schrieb: > Schau unter Linux mal in Ordner "/dev/serial/by-id/" ;-) Per udev sollten sich auch Devices erzeugen lassen die VID,PID und Serial enthalten.
Ulli schrieb: > Per udev sollten sich auch Devices erzeugen lassen die VID,PID und > Serial enthalten. Und auch vernüftige Rechte bekommen, so das die Anwendung nicht als Root laufen braucht.
g457 schrieb: > Windoofs macht das übrigens schon mehr oder weniger selbständig, > zumindest pro Maschine ist die Zuordnung persistent. Das Verhalten kann man unter Linux per udev nachbauen.
Klaus schrieb: > Satz K. schrieb: >> Aber trotzdem danke für den Klugschiss, der mich bei meinem Problem null >> weiterbringt :-( > > Und frech isser. Ob ihn das weiterbringt? Das nenne ich doch mal eine verzerrte Wahrnehmung. Ich stelle eine eindeutige, klar formulierte Frage. Statt einer passenden Antwort, erhalte ich Mutmaßungen, Erklärungen, die nicht zur Frage passen und letztendlich sogar die Unterstellung, ich sei inkompetent (Rufus T. Firefly, rkern). Wenn ich dann im gleichen Stil antworte, dann ist das plötzlich "frech". Hallo geht's noch? Und nein, die bis dahin gegebenen Antworten haben mir kein bisschen weitergeholfen, da sie nicht zu meinem Problem gepasst haben (welches ich eigentlich klar formuliert habe). Dass jemand falsche Mutmaßungen über meine Hardware anstellt, nur weil ich das gesamte Projekt auf Grund seines Umfanges nicht vollständig beschreiben kann, wird dann ebenfalls zu meinem Problem gemacht. Ein toller Umgangston ist das hier! PS: die Hinweise auf die libusb-win32 waren übrigens die richtige Antwort, entgegen der Behauptung der "Experten" hier ist es nämlich nicht maßlos kompliziert, das verhalten des COM-Treibers selber nachzustellen, mit der libusb geht diwe Kommunikation relativ einfach - sämtlichen Overhead, die seriele Schnittstelle betreffend kann ich in meinem Fall nämlich weglassen und einfach nur die Daten übertragen. Danke an die echten Experten hier und schöne Grüße an die Egozentriker.
Satz K. schrieb: > PS: die Hinweise auf die libusb-win32 waren übrigens die richtige > Antwort Die habe übrigens ich Dir gegeben. Wenn auch mit dem Hinweis, daß Du Dich da in eine falsche Richtung verrennst. Was Du ja jetzt auch getan hast.
Tja ... Du Hast nur die falsche Frage gestellt .. Richtig wäre gewesen: Warum habe die Blödel beim damaligen Design von USB nicht an mein Protokoll gedacht, das ich mir gestern Abend ausgedacht habe ? Und schon hättest du sofort die richtige Antwort bekommen ;)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.