Hallo zusammen, ich bin gerade dabei ein Protokoll über USB zu tunneln. Im Moment nehme ich ein MCB2140 Board, das als HID Gerät erkannt wird. Von einem "Experten" habe ich erfahren, das die Art wie ich es im Moment mache sehr unschön und nicht dem USB Gedanken entsprechend ist. Also beim lesen bitte nicht zu schockiert sein :) Ich baue also einen Tunnel über die Input/Putput Reports auf (bis jetzt nur einem in jede Richtung). 16 Byte gehen rein und 4 kommen zurück. Mein Protokoll zerstückel ich einfach in 4 bzw. 16 Byte große Häpchen und dann versende ich sie. Wenn das USB Board keine Daten zum senden hat, dann schickt er einfach 0 0 0 0. Hat einer von euch eine bessere Idee, wie man das machen könnte? Andere Klasse verwenden? Treiber schreiben? ... Bin für jeden Tipp dankbar. Grüße Nils
wenn du in der Lage bist einen Treiber zu schreiben würde ich das tun. Ansonsten schau mal nach libusb das gibts auch für Windows. Die Kommunikation würde ich über Controllrequests (Vendor) abwickeln. Bei größeren Datenmengen ev auch über Bulk. HID halte ich für langsam und umständlich. Der einzige Vorteil ist halt dass kein Treiber notwendig ist. Ein Treiber der in der Lage ist über IOCTL Control Requests abzuwickeln ist relativ schnell geschrieben. Bespiele dazu gibt es in den DDKs. Vieleicht auch eine Alternative www.thesycon.de Thomas
Eigentlich wollte ich libusb nicht verwenden, da das Gerät später mal in Produktion gehen soll und da sollte es sich dann auch als richtiges USB Gerät anmelden. Soviel ich weiss tauscht ja libusb einen Teil des Win Usb Stack aus und greift ohne einen Treiber direkt auf das Gerät zu oder? Es gibt doch Klassen, die BULK können. Wie siehts zB mit der Data-Interface Klasse aus? Kennt die jemand? Grüße Nils
Hallo Nils, ich weiss nicht ob ich mich als Experte bezeichnen kann, aber: Wenn Dir die Transferrate von einem HID genügt dann bleibe unbedingt bei dieser Klasse. Der Vorteil, dass man keinen Treiber braucht ist einfach immens. Und mit dem DDK ist gar nichts (Funktionierendes) schnell geschrieben! Es erfordert sehr fundierte Kentnisse (und BTW: den Besitz desselben) die man sich erst mal aneignen muss. Ich habe selbst viel Zeit damit verbracht meine Geräte zum HID zu machen und jedesmal wenn ich diese an einen neuen PC anschließe bin froh, dass ich keinen Treiber installieren muss. Martin
@Martin: Vielen Dank für deine Antwort. Einen eigenen Treiber will ich wirklich nicht programmieren, aber es kann sein, dass die Firma da nicht drum rum kommt (dann aber erst nach meiner Bachelor Arbeit). Den eigenen Treiber lassen wir also mal ausser acht, ich bin aber gerade dabei mir die anderen USB Klassen anzusehen und die "Data Interface Class" sieht doch ganz ok aus, für das was ich vorhab. Dafür müsste es doch auch schon Treiber geben, oder? HID reicht leider auf die dauer nicht mehr aus für die Geräte, da in naher zukunft auch Messdaten übertragen werden sollen und da es um Sicherheitstechnik geht, sollte da schon was schnelles her.
Hallo Nils, ich weiss nich welches Buch Du hast, in meinem "USB Complete" gibt es keine "Data Interface Class" oder ich hab sie auf die Schnelle nicht entdeckt. Für Dich kommt vielleicht die "Test and measurement class" in Frage aber die hat kein garaniertes Timing... Bei all meinen Bemühungen habe ich erst einaml den Treiber vom Chiphersteller des Devicechips benutzt. Nachdem ich damit Erfahrung gesammelt habe, habe ich das umgebaut zum HID. Die Nutzung dieser Klasse scheint mir immer "höherwertiger" solange die Transferrate reicht, egal wie die Daten zerstückelt werden müssen. MfG Martin
Morgen Martin, vielleicht hab ich mich da auch vertan, ist wohl ein teil der communication-device-class, wurde aber in meinem buch (usb2.0 / H.J.Kelm) nicht so wirklich drauf eingegangen, deswegen kannst du recht haben.
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.