Hallo Ich versuche eine Hardware anzusteuern, die am USB hängt. Die hardware hat 2 Interfaces. Das erste ist ein MassStorageDevice und das zweite hat keine (Standard)Spezifikation. Man kann einfach Daten senden. Das MSD ist mit Enpoint 1 und 2 verbunden. Das andere Interace nutzt Endpoint 3 und 4. Ich möchte nun mit meiner Applikation mit EP3 und 4 kommunizieren. Mit LibUSB hab ich das schon hinbekommen, jedoch hab ich große probleme mit der Stabilität. Wie mit google verraten hat, ist LibUSB nicht multithreading Safe, noch werden konkurrierende Prozesse unterstützt. Wie ist sowas hinzubekommen? Man müsste Windows XP irgendwie sagen, dass USB jetzt ganz alleine mir gehört und das gewartet werden soll. Hat mit soetwas jemand Erfahrung? MFG
:
Verschoben durch Admin
>google verraten hat, ist LibUSB nicht >multithreading Safe Was meinst Du damit genau? Unter Linux hatte ich mit libusb keine Probleme mit meiner Platine zu kommunizieren und gleichzeitig USB-Mouse, Keyboard und Drucker zu nutzen. Das sollte ja auch wohl selbstverständlich sein. Wobei es seit damals wohl mindestens eine neue Version von LibUSB gibt, aber es sollte ja nicht schlechter geworden sein... Oder beziehst Du dich nur auf Windows7?
>Windows XP irgendwie sagen,
Da habe ich nicht aufgepasst...
Aber ich verstehe es nicht, dann wäre libusb für Windows ja praktisch
nutzlos. Kannst Du angeben, was Du mit Google gefunden hast?
Nur windows. Und: bei dir waren Mouse und Tastatur sicher getrennte Devices. Damit hätte ich auch keine Probleme. Hier ist es EIN Gerät mit 2 Interfaces, das von 2 Programmen gleichzeitig benutzt wird. Dabei scheint es zu gegenseitigen Blockierungen oder Kollisionen zu kommen. Kollision natürlich nicht auf dem Bus, sondern auf Treiberebene.
Ah ja, jetzt verstehe ich Dein Problem. Das ist wohl echt kompliziert.
Ich frage mich aber gerade warum das ganze überhaupt probleme macht :-/ Auch eine kollision von treiberzugriffen dürfte doch das USB protokoll auffangen, denn die Anfragen gehen an verschiedene Endpoints. Liegt es vielleicht an etwas anderem? Symptome: Zugriff auf die KOmmunikationsendpoints funktoinieren nur zufällig. Sobald es einmal nicht funktoineirt, muss ich komplett neu connecten damit mein gerät wieder ansprechbar ist. MFG
Ich würd mal nen USB Monitor dazwischen schalten und nen funktionierenden Zyklus mit einem der nicht funktioniert vergleichen. Möglicherweise gibts ne race condition am control endpoint.
OK, guter ansatz erstmal: Das 2. Interface das ich eingerichtet habe um einfach nur auf die 2 zusätzlichen Endpoints zuzugreifen.. Muss ich da am Control-Endpoint irgendwas beachten? Auf was muss der reagieren... bis jetzt hab ich wirklich nur die beiden zusätzlichen Endpoints konfiguriert und reagiere auf einkommende Pakete. Der Rest ist von Atmels MassStorageDevice-Beispiel (wo nicht 2 Interfaces zum einsatz kommen) Ich frage in die Richtung, da die Kommunikation per LibUSB immer meint "Cant read DeviceDescriptor" und danach kann das gerät bis zu einen reconnect nicht mehr enumeriert werden. Was muss ich am ControlEndpoint beachten?
DerAlbi schrieb:
> Was muss ich am ControlEndpoint beachten?
Timing
Aber ob ein HID-Vendor-Hybrid (composite device) überhaupt mit
LibUSB-Win32 funktioniert ...
Zumindest sollte das composite device als zwei geräte im device manager
auftauchen.
OK, und wie erreicht man das? Da müsste der Host bei der Enumeration den EP0 ja mehrmals die Fragestellen wer er ist. Tut er das, Wenn JA, wann und wie bekomm ich das raus?
Ein weiteres Problem: ich will eigentlich gar nicht, dass man für das gerät irgendwelche Treiber installieren muss oder das Windows danach fragt. Ich will wirklich NUR die 2 zusätzlichen Endpoints haben für mein Debug-Programm. MFG
DerAlbi schrieb: > ich will eigentlich gar nicht, dass man für das > gerät irgendwelche Treiber installieren muss oder das Windows danach > fragt. Dann brauchst du dafür auch n HID interface. Und die enumeration der 2 Geräte erfolgt per composite device in einem Rutsch. Such dir da lieber mal gute Literatur; hab das Gefühl als ob das derzeit eher nach copy-paste-modify abläuft.
Du meinst also ich soll das Gerät sozusagen als Maus anmelden? Du hast recht. USB ist komplex. Das dauert ewig. Ich bin schon froh, dass ich die MSD-Software auf meinen Ap7000 portieren konnte. Deswegen ist was wirklich nur angepasste Software. Was Literatur angeht: ich hab mich bemüht, aber entweder man ließt alles und versteht nix, oder man schneidet ein wenig etwas mit, wenn man die Zusammenfassungen ließt. PRoblem am HID wird doch sein, dass auch das einem bestimmten Protokoll folgt oder? Zu viel aufwand. Ich habe mein Eigenes Protokoll das einfach nur zwischen meinem Gerät und meinem PC-Programm laufen soll. Das kann doch nicht sooo schwer zu erreichen sein :-/
DerAlbi schrieb: > Ich will wirklich NUR die 2 zusätzlichen Endpoints haben für mein > Debug-Programm. Wenns eh nur ums Debugging geht, dann reicht doch RS232? Ein USB CDC COM Port mit Mass Storage Device wär da schon einfacher zu realisieren, da es zu beidem Beispielcode von Atmel gibt. Außerdem kommst du dann ohne LibUSB aus. Der Weg über ne HID Maus wird nicht funktionieren, dann würden ja die Debugmeldungen als Mausbewegungen interpretiert :P Bei den HID usage pages könnte ab 0x0B was dabei sein, hatte aber mit denen noch nix zu tun.
Problem bei dem ganzen ist, dass ich richtig hohge Datenraten (gut & gerne 10MB/s) habe und das ganze per dma steuerbar sein muss. Wenn ich mich da wirklich an irgendein protokoll halte blockiert mir das zu viele freiheiten. Ich denke wirklich, dass ich gaaaanz einfach nur die Enumeration des Conpositdevices ghinbekommen muss. Ich habe ja wie gesagt meinen DeviceDescriptor schon angepasst.. und wenn ich die Enumeration des MSD verbugge, sagt mir der Gerätemanager auch schon dass da ein verbundgerät dran hängt. Wird das MSD enumeriert, gibt es aber kein weiteres unbeakanntes gerät. Ich habe bisher noch keine wirklich hilfreichen Dokumente gefunden die mir genauer beschreiben wie die Enumeration funktioniert. Irgendwo muss ja am ControllEndpoint der InterfaceIndex mitgeliefert werden, der gerade enumeriert werden soll. den habe ich bisher noch nicht gefunden bzw hätte er sinnlose werte. MFG
Also ich habe mich jetzt doch nocheinmal mit EasyUSB hingesetzt und die Inkmpatibilitäten zum Borland Compiler geflickt. Mein Programm läuft jetzt auch als CompositeDevice perfekt stabil! Aaaaber: easyUSB ist ja sooooo laaahhhhm. Mit LibUSb hatte ich locker 12Mb/s.. EasyUSBconnect schrumpft das auf 1.2MB/s zusammen. Ich bin jetzt ein wenig gefrustet. Jetzt hab ich stabilität gegen Bandbreite getauscht. Problem dabei: ich brauch die Bandbreite dringend. (muss bitmaps übertragen) Die Bandbreite dafür ist jetzt schon eng. Hat jemand erfahrung mit easyUSBconnect?? Ist die Begrenzung typisch für diesen Treiber? Kann eventuell der EndpointTyp etwas ändern? Vielleicht ist der Bulk-transport schuld? Beschränkt EasyUSB vielleicht auf Fullspeed?? Wie könnte man das ändern? Meinungen! (bitte) MFG
> Mit LibUSb hatte ich locker 12Mb/s.. > EasyUSBconnect schrumpft das auf 1.2MB/s zusammen. Wenn Du dich jetzt an die Konvention gehalten hast, mit "b" Bit und mit "B" Byte zu meinen, dann ist das mit dem "schrumpfen" ironisch gemeint, oder wie jetzt?
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.