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
>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.
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?
