Hallo zusammen,
ich habe einen Atiny85, der meldet sich über den usb-descriptor als
"Human Interface Device" (Wert 3) an, und wird dann als "USB Input
Device" in dieser Gruppe dargestellt (Gerätemanager)
Dann löse ich manuell oder via DevCon eine WinUSB *.inf aus, in der
steht ledeglich das dass Gerät nun unter der ID:
ClassGuid = {88bae032-5a81-49f0-bc3d-a4ff138216d6}
zu einem "Universal Serial Bus device" mutieren möge. Was auch statt
findet.
Erst hier ist es möglich über das Interface zu kommunizieren.
Wie kann ich es machen das sich der Baustein von Vornherein als
"Universal Serial Bus device" anmeldet ? (usbconfig.h via Vusb)
Vielen Dank für Hinweise
Karsten
Eine entsprechende inf datei mit den usb vid,pid des attiny erstellen. Alternativ diese auf "bekannte" werte setzen
Hi, ja das ist schon klar, ich habe eine *inf hergestellt, ich arbeite ohne fremde libs, kein libusb, nur WinUSB (SystemBestandteil seit XP) , auch wird kein bootloader eingesetzt. Auf die USB -Systemanfragen nach dem einstecken,antwortet der Atiny mit einer device descriptor Tabelle, und fällt dann in die USB Hid -Geräteklasse, wo ich Ihn nicht ansprechen kann. Nach der Installation der *.inf Datei, kann ich den Baustein mit meinem TreiberOpener via CreateFile und DeviceMSG's verwenden (lesen/schreiben). In dieser *.inf steht nicht viel drin, es müsste möglich sein das der Baustein selbst in die usb-klasse: "Universal Serial device" springt. Es hat sich mir noch nicht offenbart wie das geht. Danke für deine Antwort Gruß Karsten
Karsten S. schrieb: > antwortet der Atiny mit einer device descriptor Tabelle, > und fällt dann in die USB Hid-Geräteklasse, Tja. Dann steht das so im Descriptor drin. Den musst Du dann ändern.
Karsten S. schrieb: > ich habe einen Atiny85, der meldet sich über den usb-descriptor als > "Human Interface Device" (Wert 3) an, Ja. Eigentlich ist genau DAS eine üble Sache. Die HID-Geräteklasse sollte man besser den Dingen überlassen, die tatsächlich HID-Geräte sind, also Tastaturen, Mäuse und dergleichen. Dein ATtiny ist aber vermutlichst kein derartiges Gerät, sondern irgendwas anderes, was vermutlichst in der CDC-Klasse viel besser aufgehoben wäre. Also solltest du sowohl die Descriptoren als auch das Verhalten deines ATtiny entsprechend umstellen. Beispiele hierzu gibt es genug - selbst hier in diesem Forum. nochwas: Ich hatte vor 2..3 Jahren auf der Embedded erlebt, daß dort sowas wie Billig-Einmal-USB-Sticks aus Plastik von ST und anderen als Werbegeschenke verteilt wurden. Das waren Dinger, bei denen es sich herausgestellt hatte, daß sie verkappte HID-Devices waren, die als Tastaturen fungierten und einem eine Kommandozeile mit dem Aufruf des Browsers zu irgend einer Werbe-Internetseite unterjubelten. In meinen Augen fast sowas wie ne Virenschleuder! Vielleicht verstehst du jetzt, daß es tatsächlich ein übles Ärgernis ist, die HID-Klasse für was anderes als tatsächliche HID-Geräte zu verwenden. W.S.
W.S. schrieb: > Die HID-Geräteklasse sollte man besser den Dingen überlassen, die > tatsächlich HID-Geräte sind, also Tastaturen, Mäuse und dergleichen. HID ist außer Mass Storage so ziemlich die einzige Geräteklasse, die von allen möglichen Betriebssystemarten und -versionen standardmäßig unterstützt werden, ohne dass man einen Treiber mitliefern muss. Wenn das HID sich dabei nicht also Tastatur oder Maus registriert, ist die Sache auch einigermaßen sauber. Die einzige wirklich relevante Einschränkung besteht darin, dass man nur über den Control Endpoint mit seinem Gerät plaudern kann. Daher bietet es sich für Gerätehersteller durchaus an, Geräte ohne große Anforderungen bezüglich Datenübertragungsgeschwindigkeit als HID zu realisieren, auch wenn sie eigentlich keine HIDs sind. Die beiden wichtigsten Gründe, warum man nicht hierbei nicht auf CDC ACM setzt, bestehen darin, dass Windows XP keinen ordentlichen CDC-Treiber mitliefert und dass CDC-ACM-Geräte als COM-Ports auftauchen und daher leicht verwechselt werden. Die schlechten HID-Treiber sind auch der Grund, weswegen fast alle Hersteller von USB-RS232-Schniepel-Chips nicht auf CDC setzen, sondern ein eigenes Register- und Endpointmodell einsetzen und eigene Treiber mitbringen. Mit dem allmählichen Aussterben von Windows XP reduziert sich der Vorteil von HID aber wieder etwas. Und einen Treiber für Linux zu unterstützen, ist eine äußerst lästige Sache, da man die Kompilierbarkeit für etliche Kernelversionen sicherstellen muss. Dort gibt es aber wenigstens schon sehr lange ordentliche CDC-ACM-Treiber und natürlich HID. Leider gibt es aber einige Distributionen, deren Hardwareerkennung und/oder Startupskripte versuchen (oder früher versucht haben), mit jeder seriellen Schnittstelle einen getty- oder (Fax-)Modem-Prozess laufen zu lassen. So etwas führt dann zu langwieriger Fehlersuche.
Andreas S. schrieb: > HID ist außer Mass Storage so ziemlich die einzige Geräteklasse, die von > allen möglichen Betriebssystemarten und -versionen standardmäßig > unterstützt werden, ohne dass man einen Treiber mitliefern muss. Heutzutage würde ich keine spezifierte Klasse wählen und mich auf den WinUSB-Treiber verlassen (ab Vista). Ist flexibler (aber für kaum einen µC dokumentiert, von Beispielcode ganz zu schweigen). > Und einen Treiber für Linux zu unterstützen, ist eine äußerst lästige > Sache, da man die Kompilierbarkeit für etliche Kernelversionen > sicherstellen muss. Besser libusb im Userspace nehmen. > Leider gibt es aber einige Distributionen, deren Hardwareerkennung > und/oder Startupskripte versuchen (oder früher versucht haben), mit > jeder seriellen Schnittstelle einen getty- oder (Fax-)Modem-Prozess > laufen zu lassen. So etwas führt dann zu langwieriger Fehlersuche. Dass andere Programme versuchen, eine serielle Schnittstelle anzusprechen, ist natürlich in jedem Betriebssystem möglich. Es ist also in jedem Fall zu empfehlen, die Firmware dagegen abzusichern.
W.S. schrieb: > Die HID-Geräteklasse sollte man besser den Dingen überlassen, die > tatsächlich HID-Geräte sind, also Tastaturen, Mäuse und dergleichen. Und warum? HID lässt sich hervorragend zum Austausch jeglicher Daten verwenden. Warum auch nicht? Dem Gerät ist es nämlich egal, was Du rausschickst. W.S. schrieb: > Ich hatte vor 2..3 Jahren auf der Embedded erlebt, daß dort sowas wie > Billig-Einmal-USB-Sticks aus Plastik von ST und anderen als > Werbegeschenke verteilt wurden. Das waren Dinger, bei denen es sich > herausgestellt hatte, daß sie verkappte HID-Devices waren, die als > Tastaturen fungierten und einem eine Kommandozeile mit dem Aufruf des > Browsers zu irgend einer Werbe-Internetseite unterjubelten. In meinen > Augen fast sowas wie ne Virenschleuder! Vielleicht verstehst du jetzt, > daß es tatsächlich ein übles Ärgernis ist, die HID-Klasse für was > anderes als tatsächliche HID-Geräte zu verwenden. Als ob daran das HID schuld wäre. Was für ein Blödsinn. Das liegt wohl eher am Entwickler. Andreas S. schrieb: > HID ist außer Mass Storage so ziemlich die einzige Geräteklasse, die von > allen möglichen Betriebssystemarten und -versionen standardmäßig > unterstützt werden, ohne dass man einen Treiber mitliefern muss. Wenn > das HID sich dabei nicht also Tastatur oder Maus registriert, ist die > Sache auch einigermaßen sauber. Die einzige wirklich relevante > Einschränkung besteht darin, dass man nur über den Control Endpoint mit > seinem Gerät plaudern kann. Leider stimmt auch das nicht, denn: 1. Die 'Sache' ist immer sauber. Man muss es nur richtig machen! 2. Ein HID-Gerät benötig Interrupt Endpunkte und genau diese Tatsache sollte einem sagen, dass eben (im Normalfall) nicht über Control-Endpunkte kommuniziert wird. Clemens L. schrieb: > Heutzutage würde ich keine spezifierte Klasse wählen und mich auf den > WinUSB-Treiber verlassen (ab Vista). Ist flexibler (aber für kaum einen > µC dokumentiert, von Beispielcode ganz zu schweigen). Der WinUSB-Treiber kommunziert doch mit CDC-Geräten, oder? Und ist das keine 'spezifizierte Klasse'? Tut mir leid, dass das hier etwas giftig wurde, aber wenn man das so liest, dann gibt es nur einen Grund, warum kein HID verwendet wird: Weil viele Leute von USB einfach keine Ahnung haben.
Knut schrieb: > Clemens L. schrieb: >> Heutzutage würde ich keine spezifierte Klasse wählen und mich auf den >> WinUSB-Treiber verlassen (ab Vista). > > Der WinUSB-Treiber kommunziert doch mit CDC-Geräten, oder? Und ist das > keine 'spezifizierte Klasse'? Nein, WinUSB unterstützt beliebige USB-Transfers (isochrone erst ab Windows 8). https://msdn.microsoft.com/en-us/library/windows/hardware/ff540196.aspx: > Windows USB (WinUSB) is a generic driver for USB devices [...]. > The WinUSB architecture consists of a kernel-mode driver (Winusb.sys) > and a user-mode dynamic link library (Winusb.dll) that exposes WinUSB > functions. By using these functions, you can manage USB devices with > user-mode software. https://msdn.microsoft.com/en-us/library/windows/hardware/hh450799.aspx: > A WinUSB device is a Universal Serial Bus (USB) device whose firmware > defines certain Microsoft operating system (OS) feature descriptors > that report the compatible ID as "WINUSB". > > The purpose of a WinUSB device is to enable Windows to load Winusb.sys > as the device's function driver without a custom INF file.
:
Bearbeitet durch User
Hi,
also ich habe auch die USB Specs gesichtet, es ist eine tonne von Infos.
Was ich habe ist ein Atiny85 und ein stück VUsb implementation.
Hier kann man sich in der usbconfig entscheiden ob man
einen eigenen descriptor definiert über einige defines.
Auszug: (usbconfig.h)
#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH 22
ist dieser define aktiv wird als descriptor folgendes Array zum Host
gesendet:
PROGMEM const char usbHidReportDescriptor[22] = { // USB report
descriptor
0x06, 0x00, 0xff, // USAGE_PAGE (Generic Desktop)
0x09, 0x01, // USAGE (Vendor Usage 1)
0xa1, 0x01, // COLLECTION (Application)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x01, // REPORT_COUNT (1)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
0xc0 // END_COLLECTION
};
Hiermit mutiert das Gerät gerade wohl in zwei Geräte als HID
USB Input Device
Leider recht patzig dargestellt alles in einem Array zu stopfen,
die eigentliche Definition des Deskriptors sieht so aus:
typedef struct {
unsigned char bLength; // Sizeof this Descriptor in Bytes
unsigned char bDescriptorType; // Descriptor Type (=1)
unsigned int bcdUSB; // USB Spec Release Number in BCD
unsigned char bDeviceClass; // Device Class Code
unsigned char bDeviceSubClass; // Device Subclass Code
unsigned char bDeviceProtocol; // Device Protocol Code
unsigned char bMaxPacketSize0; // Maximum Packet Size for EP0
unsigned int idVendor; // Vendor ID
unsigned int idProduct; // Product ID
unsigned int bcdDevice; // Device Release Number in BCD
unsigned char iManufacturer; // Index of String Desc for
Manufacturer
unsigned char iProduct; // Index of String Desc for
Product
unsigned char iSerialNumber; // Index of String Desc for SerNo
unsigned char bNumConfigurations; // Number of possible
Configurations
} device_descriptor; // End of Device Descriptor Type
Verwende ich die PID und VID von Voti (VID_16C0 PID_05DC)
lande ich tatsächlich als Univerasl Serial device im GeräteManager.
verändere ich die VID PID zu VID_16C1 PID_15DC)
Wird wieder das besagte HID Input device draus.
Sicherlich habe ich eine *inf Datei, wann immer ich die installiere
mutiert das Gerät dahin wo ich möchte, ich will aber das dieses Gerät
durch den Deskriptor selbstständig richtig einsortiert wird.
Ansonsten kannst Du im Deskriptor reinschreiben was Du möchtest.
Es bleibt mir weiterhin unverständlich wie nun der Descriptor aussehen
soll
für ein "Universal Serial device" und warum die Inhalte scheinabr in der
länge varieren dürfen.
Auch ist mir unklar wie ich über den DeviceDescriptor die notwendige
DeviceGUID assoziieren kann, unter Voti PID/VID laufen viele Geräte,
in meiner inf Datei erteile ich eine ausgedachte DeviceGUID , mit der
ich das Gerät direkt öffnen kann ohne zb. den USBasp Programmer zu
"treffen" oder sonnstiges mit gleicher pid/vid , wie kann das System die
pid/vid überhaupt mit Voti in Verbindung bringen, libusb erscheint mir
wie eine systemseuche . Wesswegen ich jede Querverbindung im Moment
meide.
Mein Gerät funktioniert wunderbar von XP - w10 ohne voti.
Leider nur mit meiner Inf die ich immer mit DevCon oder von Hand updaten
muss:
; KeyMan.inf
; Copyright (c) 1998-2015 KarstenSchulz
[Strings]
DeviceName = "KeyMan"
VendorName = "KarstenSchulz"
DeviceID = "VID_16C1&PID_15DF"
DeviceGUID = "{EEBE3F79-3A2A-4304-9791-EBF0E998E93F}"
[Version]
Signature = "$Windows NT$
ClassGuid = {88bae032-5a81-49f0-bc3d-a4ff138216d6}
Provider = "KarstenSchulz"
DriverVer = 30/11/2015, 8.0.0.0
[ClassInstall32]
Addreg = WinUSBDeviceClassReg
[Manufacturer]
%VendorName% = KarstenSchulz_WinUSB,NTx86,NTamd64,NTia64
[KarstenSchulz_WinUSB.NTx86]
%DeviceName% = USB_Install, USB\%DeviceID%
[KarstenSchulz_WinUSB.NTamd64]
%DeviceName% = USB_Install, USB\%DeviceID%
[KarstenSchulz_WinUSB.NTia64]
%DeviceName% = USB_Install, USB\%DeviceID%
[USB_Install]
Include = winusb.inf
Needs = WINUSB.NT
[USB_Install.Services]
Include = winusb.inf
AddService = WinUSB,0x00000002,WinUSB_ServiceInstall
[WinUSB_ServiceInstall]
DisplayName = "WinUSB - Kernel Driver 0/11/2015 8.0.0.0"
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys
[USB_Install.Wdf]
KmdfService = WINUSB, WinUsb_Install
[USB_Install.HW]
AddReg = AddDeviceInterfaceGUID
[AddDeviceInterfaceGUID]
HKR,,DeviceInterfaceGUIDs,0x10000,%DeviceGUID%
HKR,,FriendlyName,,"KeyMan"
Verwendet wird AtmelStudio2015 und ein USBasp via AvrDude
Danke für Hinweise :)
gruß
Karsten
Karsten S. schrieb: > PROGMEM const char usbHidReportDescriptor[22] = { // USB report > descriptor > 0x06, 0x00, 0xff, // USAGE_PAGE (Generic Desktop) > 0x09, 0x01, // USAGE (Vendor Usage 1) > 0xa1, 0x01, // COLLECTION (Application) Das passt eben nicht für ein HID Device. Wenn ich mal kurz zitieren darf ( aus "Device Class Definition for Human Interface Devices (HID) Firmware Specification—6/27/01) : "The HID class consists primarily of devices that are used by humans to control the operation of computer systems. Typical examples of HID class devices include: * Keyboards and pointing devices—for example, standard mouse devices, trackballs, and joysticks. * Front-panel controls—for example: knobs, switches, buttons, and sliders. * Controls that might be found on devices such as telephones, VCR remote controls, games or simulation devices—for example: data gloves, throttles, steering wheels, and rudder pedals. * Device Class Definition for Human Interface Devices (HID) Version 1.11 6/27/00: * Devices that may not require human interaction but provide data in a similar format to HID class devices—for example, bar-code readers, thermometers, or voltmeters. Many typical HID class devices include indicators, specialized displays, audio feedback, and force or tactile feedback. Therefore, the HID class definition includes support for various types of output directed to the end user. " Wenn dein Device also im Sinne des Wortes ein HID Device ist, sollte es unter einer dieser Klassen fallen - ausdrücklich gehört CDC nicht dazu. Wenn du dir eine Vendor-spezifische Klasse ausdenkst, musst du eben auch ein *.inf mitliefern.
:
Bearbeitet durch User
Karsten S. schrieb: > Es bleibt mir weiterhin unverständlich wie nun der Descriptor aussehen > soll für ein "Universal Serial device" Die Device-/Interface-Deskriptoren sollten als Klasse "vendor specific" (0xff) haben, damit dir kein Klassentreiber in die Quere kommt. Damit WinUSB automatisch läuft, brauchst du noch einen Microsoft OS Descriptor: https://msdn.microsoft.com/en-gb/library/windows/hardware/ff537430.aspx Besser erklärt auf https://github.com/pbatard/libwdi/wiki/WCID-Devices. Und du solltest keine VID/PID von einem Gerät klauen, dessen .inf etwas anderes spezifiziert.
:
Bearbeitet durch User
Clemens L. schrieb >>Wenn du dir eine Vendor-spezifische Klasse ausdenkst, musst du eben auch >>ein *.inf mitliefern. Danke das ist wohl der Punkt, wenn ich kein Joystick/key/mouse.. bin brauche ich immer eine *.inf Datei, und zweitens wenn ich in einer nicht Hid Klasse abhänge, darf ich mir auch keine PID/VID ausdenken. Sondern muss eine dem System bekannte VID verwenden, es reicht schon das ändern der VID und mein Gerät verfällt in ein unknow gerät, bis ich die *.inf installiere. Dann ist wieder alles fein. Und dann ist es egal ob ich einen descriptor habe , ich brauch dann keinen descriptor mehr. Da die *inf das Gerät eh installiert, und dann ist es sogar egal welche PID/VID ich verwende. Sehr bedenklich. Ich "glaube"(Gegenteil von wissen) genau so läuft das. Meine Vision war, ich kann in dem Descriptor quasi die *inf ersetztn. Das letzte Mysterium bleibt dann die DeviceGUID(nicht die ClassGUID) Nur mit der selber ausgedachten DeviceGUID kann ich das Gerät überhaupt öffnen das enumerieren der GerätePfade liefert nämlich immer den ClassGUID und nicht den DeviceGUID ohne dem schlägt CreateFile direkt fehl. Ich habe natürlich auch die USB-Dokus eingesehen, verinnerlichen oder manifestieren wollte ich die KartellVorschriften nicht so gerne, ist auch viel Holz. Danke erstmal für alle Kommentare, der Dialog ist es der hilft, nicht der Inhalt :( Karsten
Karsten S. schrieb: > Clemens L. schrieb Nein, das war nicht ich. > Danke das ist wohl der Punkt, wenn ich kein Joystick/key/mouse.. bin > brauche ich immer eine *.inf Datei Nein. Auch für WinUSB hat Windows schon eine .inf-Datei dabei. > wenn ich in einer nicht Hid Klasse abhänge, darf ich mir auch keine > PID/VID ausdenken. Sondern muss eine dem System bekannte VID verwenden Nein! Du darfst keine Vendor ID von jemand anderem klauen. Du musst eine vom USB-Konsortium kaufen, oder kannst (falls Open Soße) dir von OpenMoko eine PID zuteilen lassen. > Meine Vision war, ich kann in dem Descriptor quasi die *inf ersetztn. Das kannst du.
Clemens L. schrieb: > Nein! Du darfst keine Vendor ID von jemand anderem klauen. Du musst eine > vom USB-Konsortium kaufen, oder kannst (falls Open Soße) dir von > OpenMoko eine PID zuteilen lassen. Wenn es nicht verkauft und nur privat eingesetzt wird, kann man sich schon eine Vendor ID "klauen". Man muss aber mit der Einschränkung leben, dass diese bereits irgend einem Treiber bekannt ist.
Du kannst auch ein generic HID machen ohne Maus, Tastatur usw. So machen die das beim IoWarrior. Dann brauchst du auch keine inf und das Gerät taucht nur als HID auf. Für Winusb brauchst du aber eine inf, oder halt die os descriptoren, wobei die nur ab Windows 7 ausgewertet werden soweit ich weiß. Dann musst du die Device guid nehmen die MS in die winusb.inf reingepackt hat.
Hi, >Dann musst du die Device guid nehmen die MS in die >winusb.inf reingepackt hat. So sieht das nämlich aus ! Danke Gruß Karsten
Hi,
schade mit der DeviceID aus WinUSB.inf :
{0xF72FE0D4, 0xCBCB, 0x407d, {0x88, 0x14, 0x9E, 0xD6, 0x73, 0xD0, 0xDD,
0x6B}}
Kann ich mein Gerät nicht öffnen, es sei denn ich gebe diese in der *inf
an
oder erfinde eine , Wie diese DeviceID nun über den Descriptor bekannt
gegeben kann, ist der Schlüssel zum öffnen des Device mit CreateFile.
Hat schon mal jemand eine DeviceID über den Descriptor veröffentlicht ?
Du musst diesen OS Descriptor in der Firmware setzen dann lädt Windows automatisch diese inf. Und dann kannst du das Device öffnen.
Hallo Christian,
"(W7) nö ist alles ab XP"
also das Gerät ist erfolgreich in der Hid-klasse angekommen,
in der WinUSB.inf steht auch eine Microsoft DeviceGuid:
[ADB.HW.AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{F72FE0D4-CBCB-407d-8814-9ED673D0DD6B
}"
Für mich wird das Gerät aber erst zugänglich, wenn ich selber eine
DeviceGuid über das installieren einer eigenen *inf auslöse.
Die wiederum verwiest inhaltlich auf die WinUSB.inf und *.sys unter der
Geräteklasse : "Universal Serial device" . Dort meldet diese eigene *inf
das Gerät um/an, und es ist ansprechbar weil ich diese deviceGuid kenne.
Es gab kein Iterationsobjekt das mir diese DeviceGuid lieferte, somit
waren alle versuche den Path auf das Gerät zu erhalten, am Ende mit der
classGuid versehen, was aber nicht ausreicht um ein Gerät dieser Gruppe
zu öffnen. Warum liefert der Path eine ClassGuid ist völlig sinnlos..
Im Moment bin ich auf dem Stand:
1) reinstecken, ->Hid Input unansprechbar Atiny85 übertrug eigenen
Descriptor siehe VUSB. (macht wenig unterschied kann man auch weg
lassen)
2) eigene Inf installieren mit bekannter DeviceGuid, Gerät wird
verschoben
3) Geräte -Path besorgen mit Angabe dieser bekannten deviceGuid
4) Gerät öffnen und los geht's.
Gewünscht ist Schritt 2 zu entfernen , ich glaube nicht das dies schon
jemanden gelungen ist :) Bisher konnte ich über den DeviceDescriptor auf
dem Baustein lediglich bestimmen in welcher GeräteGruppe der nach dem
Einstecken landet, mehr nicht. (es handelt sich um ein null Endpunkt)
dieser kommuniziert lediglich über DeviceMessages.
Das Hauptproblem ist eigenlich, woher diese DeviceGUID kommt, sie
scheint erst zu existieren nachdem man sie anlegt mit der eigenen *inf,
sie landet in einem gschützten Bereich der Registry. Jeder verscuh
Details über das eingelegte HID Gerät zu bekommen schlägt fehl ohne das
die eigene *inf installiert wurde, passend dazu schlägt Dito fehl der
Versuch die Hitklassen zu enumerieren : HidD_GetHidGuid(&HidGuid);
Das Gerät wird erst gelistet wenn es mit einer *inf Datei verbunden
wurde.
Ich habe mich gerade damit abgefunden, und verlagere die Forschung auf
wichtigeres, muss ich halt beim installieren der Software, diese inf mit
DevCon.exe auslösen/installieren was solls..
Grüße
Karsten
Karsten S. schrieb: > Im Moment bin ich auf dem Stand: > 1) reinstecken > 2) eigene Inf installieren mit bekannter DeviceGuid > 3) Geräte -Path besorgen mit Angabe dieser bekannten deviceGuid > 4) Gerät öffnen und los geht's. > > Gewünscht ist Schritt 2 zu entfernen , ich glaube nicht das dies schon > jemanden gelungen ist :) Ich würde ja einfach in der Liste aller USB-Geräte nach denen mit meiner PID/VID suchen, da ist es dann egal, welche GUID Windows gerade verwendet. Und diese Aufgabe würde ich an libusb delegieren. Wenn du libusb nicht willst, dann musst du halt eine Menge Code selbst schreiben ...
:
Bearbeitet durch User
Clemens L. schrieb: > Dass andere Programme versuchen, eine serielle Schnittstelle > anzusprechen, ist natürlich in jedem Betriebssystem möglich. Es ist also > in jedem Fall zu empfehlen, die Firmware dagegen abzusichern. Die Absicherung der Firmware ist das Eine, das Abhalten des Hostsystems vom Öffnen der Schnittstellen das Andere. Glücklicherweise sterben langsam, aber sicher die externen (Fax-)Modems und deren standardmäßiges Ansprechen allmählich aus.
Hi Clemens,
naja so viel Code ist das nicht und ich brauche keine fremden libs,
wozu auch, es ist ja systemkonform, und ich kann auch
sehr genau das Gerät finden mit der ausgedachten pid/vid.
Man bekommt über die Iterationen,also das durchsuchen auch einen Pfad.
Aber der DevicePfad ist ungültig, am Pfadende steht die ClassID!
Um ein CreateFile auf ein Device zu machen, muss der Pfad nicht nur
Hub Slot Port und PID und VID beinhalten, sondern auch die Geräte
ID-Guid,
diese existiert aber erst dann, wenn ich zuvor eine *inf installierte
die ich selber mache, und in der eine GuidID für das gerät vereinbart
ist.
Ohne diese Guid ist das Gerät gar nicht ansprechbar, obschon es korrekt
gelistet ist. Es geht also nicht darum wie man es macht Geräte zu
listen, sondern wie man ein Gerät öffnet dessen GeräteGuid noch nie
gesetzt worden ist.
Hier ein Beispiel wie der durch enumerierung zurückgegebene Path
aussieht:
0x0f08c60c
"\\\\?\\hid#vid_23c6&pid_13ad#6&1b98b8af&4&0000#{745a17a0-74d3-11d0-b6fe
-00a0c90f57da}"
Wie man sieht endet der mit der ClassID HID-Device
{745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Damit öffnet niemand das gefundene Gerät!
Also schnell eine *inf Datei gemacht, die dem Teil eine beliebige
deviceID
andreht, dann kann ich mir den Pfad holen und dieser sieht dann so aus:
0x00ccc60c
"\\\\?\\usb#vid_23c6&pid_13ad#5&1257636a&0&3#{eebe3f79-3a2a-4304-9791-eb
f0e998e93f}"
Der Unterschied ist nun, das ich am Ende des Pfades die ID aus der *inf
finde, und alles läuft wunderbar.
Versuche mit:
0x0f08c60c
"\\\\?\\hid#vid_23c6&pid_13ad#6&1b98b8af&4&0000#{745a17a0-74d3-11d0-b6fe
-00a0c90f57da}\001
(Am ende nach der Class eine Nummer, so wie im DeviceManager unter ID
angezeigt.
Funktioniert nicht.
Fazit : Keine Inf , kein Gespräch :)
Gruß
Karsten
Knut schrieb: > Leider stimmt auch das nicht, denn: > 1. Die 'Sache' ist immer sauber. Man muss es nur richtig machen! Leider gibt es aber etliche fehlerhafte BIOS, die einen Rechnerstart verhindern, wenn ein HID erkannt wird, welches nicht eine Tastatur oder Maus darstellt, selbst wenn die Deskriptoren des Gerätes völlig korrekt definiert sind. Gerade bei Notebooks habe ich das schon mehrmals erlebt. Einige Xserver für Linux machen Ärger bei angeschlossenen USB-Joysticks. Dann springt sporadisch der Mauscursor. Eine saubere Implementierung auf Geräteseite stellt leider nicht immer sicher, dass sich das Betriebssystem oder betriebssystemnahe Software korrekt verhält. > 2. Ein HID-Gerät benötig Interrupt Endpunkte und genau diese Tatsache > sollte einem sagen, dass eben (im Normalfall) nicht über > Control-Endpunkte kommuniziert wird. Da hatte ich mich leider falsch ausgedrückt. Die Einschränkung hätte dahingehend formuliert sein müssen, dass im Gegensatz zu Mass Storage keine durchsatzstarken Bulk-Endpoints genutzt werden können.
Karsten S. schrieb: > ich brauche keine fremden libs, wozu auch Äh, damit es funktioniert? > Man bekommt über die Iterationen,also das durchsuchen auch einen Pfad. > Aber der DevicePfad ist ungültig, am Pfadende steht die ClassID! Mach' es einfach wie libusb: https://git.libusb.org/?p=libusb.git;a=blob;hb=HEAD;f=libusb/os/windows_usb.c
Ich verstehe immer noch nicht, wieso du hier WinUSB und HID so vermatschen willst. Wieso meldet sich dein gerät immer noch als HID an? Wenn du den WinUSB ohne manuelle Treiber-Installation nutzen willst, musst du erst mal den ganzen HID Quatsch aus der Firmware des Controllers werfen. Dann musst du DeviceClass 0xFF für vendor specific reinschreiben. Und dann musst du diese beiden nicht-standardisierten OS String Descriptoren bereitstellen, in denen drin steht, dass Windows das Gerät als WinUSB Device verwenden soll. Mit HID hat das überhaupt gar nix zu tun, und es ist auch völlig klar, dass du über die WinUSB keine Geräte öffnen kannst, für die der HID Treiber geladen ist. Um WinUSB im UserSpace zu nutzen, muss auch für das Gerät der WinUSB Kernel Mode Treiber geladen sein. Entweder über inf (wie bei dir jetzt) oder über die OS Descriptoren.
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.