mikrocontroller.net

Forum: PC-Programmierung USB


USB
Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hab bei den Descriptoren etwas nicht verstanden, und zwar;

Woher wissen die Endpoints zu welchen Interfaces sie gehoeren.


Konkret: Ich hab schreib eine Firmware fuer einen uC mit 2 Interaces. 
Jedes Interface bekommt 2+1 Endpoints(In und Out, und Endpoint0). Wie 
kann ich bei den Endpoint descriptoren angeben, dass sie zum jenen 
Interface gehoeren?

Wenn ich das Device als HID anmelde und mehrere Interfaces besitzt, wird 
jedes Interface als eigenes Device im Geraetemanager angezeigt?

Gruss
Bernhard

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Woher wissen die Endpoints zu welchen Interfaces sie gehoeren.

Deskriptoren sind abhängig von der Lage. Endpoint-Descriptoren folgen 
immer einem Interface-Descriptor, stehen diesem niemals voran. Ein 
Endpunkt gehört immer zum direkt vorangegangenen Interface-Descriptor.

Beispiel:
Interface1-HID-Endpoint1-Endpoint2-Interface2-Endpoint3-Endpoint4

Endpoint1 und Endpoint2 ist Interface1 vorangegangen, dazu gehören sie 
dann auch. Von EP3 und EP4 nach links gesehen ist Interface2 der nächste 
erreichbare Deskriptor, diesem Interface gehören sie dann an.

EP0 gehört immer dem Gerät und lässt sich nicht zuordnen. Alle 
Interfaces teilen sich diesen Endpunkt.

> Wenn ich das Device als HID anmelde und mehrere Interfaces besitzt, wird
> jedes Interface als eigenes Device im Geraetemanager angezeigt?

Jawoll.

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Rene, fuer die praeziese Antwort.

Wie kann ich auf die verschiedenen Endpoints ueber HID zugreifen?

Ich hab bis jetzt immer nur Reports und Features gefunden. Mir scheint 
als laufen die alle ueber den Control Endpoint.
Ich benutze die hid.lib und setupapi.lib von MS DDK.

Gruss Bernhard

P.S. Kennt jemand ein ausfuehrliches Buch ueber USB-HID?

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie kann ich auf die verschiedenen Endpoints ueber HID zugreifen?

Du kannst das gar nicht, der Treiber entscheidet über das Was und 
Wohin, siehe unten.

>  Ich hab bis jetzt immer nur Reports und Features gefunden.

Genau so ist es, die Kommunikation mit einem HID läuft einzig und allein 
über Reports (Features sind auch in Reports verpackt). Auch werden immer 
ganze Reports verschickt. Es ist nicht möglich, nur einen Teil der in 
einem Report-Deskriptor beschrieben Daten zu versenden.

> Mir scheint als laufen die alle ueber den Control Endpoint.

Das kann sein, muß aber nicht sein. Wenn ein HID keinen Endpoint 
besitzt, muß EP0 genommen werden (Set_Report, Get_Report). Wenn das HID 
einen zusätzlichen Interrupt-IN-EP besitzt, wird natürlich dieser für 
Input-Reports verwendet. So ist es auch für die andere Richtung. Besitzt 
das HID einen Interrupt-OUT-EP, wird auch dieser OUT-EP verwendet (es 
sei denn, Du arbeitest mit Win98, erste Version).

Der Treiber weiß anhand der Deskriptoren wohin die Reports gehen / woher 
sie kommen und erledigt den Transfer für Dich. Du mußt, wie gesagt, nur 
einen gültigen Report zusammenstellen.

> Ich benutze die hid.lib und setupapi.lib von MS DDK.

Wenn Du per SetupDiGetDeviceInterfaceDetail den Pfad zum Gerät ermittelt 
und es damit geöffnet hast, sendest Du deine Output-Reports mit 
WriteFile und empfängst Input-Reports mit ReadFile.

Obacht: Wenn Du Dir die Capabilities Deines Geräts genauer anschaust 
(HidP_GetCaps, HIDP_CAPS), wirst Du feststellen, daß 
HID_CAPS.XxxReportByteLength jeweils ein Byte größer ist als der 
zugehörige tatsächliche Report. Das wird gemacht, um mit Report-IDs 
arbeiten zu können. Das erste Byte, noch vor dem eigentlichen Report, 
ist dann eben auch dieser Report-Identifier. Da ich Dir unterstelle, 
nicht mit IDs zu arbeiten, mußt Du dieses Byte nullen. Initialisierst Du 
dieses Byte nicht oder nicht richtig, werden die Funktionen ReadFile, 
WriteFile, HidD_XetFeature fehlschlagen!

> P.S. Kennt jemand ein ausfuehrliches Buch ueber USB-HID?

Jan Axelsons Werke sind zwar Bücher über den USB an sich, sind aber 
absolut HID zentriert. Ein reines HID Buch gibt es meines Wissens nicht. 
Aber für die Feinheiten gibt es immer noch die offizielle Spezifikation 
und, wenn das nicht hilft, dieses Forum hier. ;-)

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Rene
Alles super erklaert

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab ich nun folgendes Problem:

Ich frage mit SetupDiGetDeviceInterfaceDetail den Pfad meines USB-HID 
Geraetes ab, und speichere den Pfad in der Variable "devicePath". In der 
Pfadangabe kann ich den VID und PID sehen, und ist soweit richtig.
Wenn ich nun ein CreateFile ausfuehren moechte, bekomme ich ein 
INVALID_HANDLE zurueck.
Mein Aufruf sieht so aus:
HANDLE hHidDeviceHandle = CreateFile(devicePath, GENERIC_READ | 
GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);

Geraet wird ordnungsgemaess angemeldet. Ich kann die Descriptoren mit 
HClient aus dem DDK von MS abfragen und ueberpruefen.
Laut HClient stimmt alles.
Mach ich hier was falsch?

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn CreateFile fehlschlägt, erfährst Du den Grund hierfür von 
GetLastError. Diesen Fehlercode hätte ich schon gern gewusst, bevor ich 
mir weiter Gedanken mache.

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GetLastError() gibt mir 0x05 zurueck.
Laut MSDN hilfe bedeutet das "Access is denied".

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, das ist ERROR_ACCESS_DENIED (winerror.h). Das kann passieren, 
wenn das Gerät bereits belegt ist, da Du das Gerät exclusive öffnen 
willst. So wirst Du beispielsweise Schwierigkeiten bekommen, eine Maus 
exclusive zu öffnen, solange das System die Maus verwendet.

Du hast jetzt zwei Möglichkeiten zur Abhilfe:
1) Du beendest das Programm, das das HID bereits verwendet.

2) Du teilst Dir das Gerät mit dem anderen Programm (Parameter 3 von 
CreateFile). Das Teilen funktioniert natürlich nur, wenn das andere 
Programm dies zulässt und das Gerät nicht seinerseits exclusive geöffnet 
hat (also mit Parameter 3 von CreateFile = 0).

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, Loesung 1 hat geholfen. Thx
Ich benutz den TIUSB 3410 mit Application Loader.
Der Loader hatte die ganze Zeit das Device blockiert.

Bekomm jetzt erfolgreich, ueber EP0 und desweiteren EP1 im Interrupt 
Modus, Uebertragungen zustande.
Komisch ist, wenn ich BULK Transfer im Descriptor waehle, dass die 
Pakete jetzt ueber EP0 geschickt werden und nicht mehr ueber EP1.
Da EP0 nur einen 8 Byte Puffer hat werden groessere Pakete aufgeteilt, 
und meine Datenrate geht in den Keller.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein HID kommuniziert ausschließlich über Interrupt Transfers. Neben dem 
EP0 hast Du maximal einen Interrupt-IN EP und maximal einen 
Interrupt-OUT EP. Wenn einer dieser beides EPs fehlt, wird 
selbstverständlich auf EP0 zurückgefallen, Dein Bulk-EP ignoriert.

Das Verhalten, das Du siehst, ist also völlig in Ordnung. Du kannst 
sogar froh sein, daß Dir der Treiber das fehlerhafte Gerät nicht gleich 
deaktiviert und versucht, aus der verkorksten Situation noch das Beste 
zu machen.

Autor: Berni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es eigentlich möglich, verschieden große Datenpakete zu verschicken 
mit nur einem Report?
Ich möchte nicht für jede Paketgröße einen eigenen Report mit 
entsprechender Länge anlegen.



Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist es eigentlich möglich, verschieden große Datenpakete zu verschicken
> mit nur einem Report?

Wie ich bereits im zweiten Beitrag schrieb: Nein, das ist nicht möglich. 
Ein Report ist ein Report und so wird er auch verschickt.

Mach den Report groß genug, stelle den Nutzdaten die tatsächliche Länge 
voran und fülle den unbenutzten Rest mit nullen auf.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum auffüllen, ist doch unnötig.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum auffüllen, ist doch unnötig.

Die Länge eines Reports, den Du sendest, muß exakt mit der im Deskriptor 
ausgiesenen Länge überein stimmen. Du darfst nicht weniger Bytes 
übertragen als ausgewiesen. Zumindest unter meinem Windows bekomme ich 
Reports nicht gelesen, wenn ich, wie von Dir vorgeschlagen, irgendetwas 
in einer nicht bekannten Länge sende. Das füllen des FIFOs ist daher 
nicht unnötig, IMO.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.