USB HID driver development
B.Gottschalk
i need to connect a custom HID device to our Windows CE 6.0-ARM-based
Hardware platform which has got an USB host controller.
I am quiet new to Windows CE and driver development, so i need much
assitance from you.
I read a lot newsgroup-threads and didn't find one which answers my questions.
I learned, that I have to develop my own HID driver to access our HID device
and have to look at the sample-drivers in the platformbuilder-folder:
C:\WINCE600\PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\HID\CLIENTS
My attemp started with the following steps:
- In VS2005 VC++ I created a new dll project for intelligent devices
- I copied the sample files "conshid.cpp", "conshid.h" and "conshid.def" to
the project-folder and renamed the files to "MyHidDrv.cpp" and so on.
- I compiled and linked everything
- Now I have got a "MyHidDrv.dll" which I copied to the WINDOWS-Folder on
the embedded device.
Now I reached a point where I need your help!
So my questions are:
1. Why does Microsoft release an USB HID driver without any
Stream-Interface-Support like ReadFile() and WriteFile()?
2. Is it possible to write a custom HID driver without the Platform Builder,
e.g. only with Visual Studio 2005 VC++?
3. If VS2005 is ok, how can I debug the driver?
4. Is my custom HID driver an addon to the USBHID.dll or does it replace the
USBHID.dll?
5. Which registry settings are necessary to load the "MyHidDrv.dll"? (Should
only be loaded, if the HID device with our VendorID (e.g. 4711) has been
connected)
6. How can I implement a Streaming-Interface with ReadFile() and WriteFile()
to receive and send reports?
I stop here to ask, before you become bored.
I appreciate if there is any help which solves my problems.
Thanks.
(Sorry for my englisch, i am from germany.)
Silver
> 1. Why does Microsoft release an USB HID driver without any
> Stream-Interface-Support like ReadFile() and WriteFile()?
Many drivers are written as stream driver, but all they really use are
init/deinit and IOControls. There is so much going on in a USB stack that it
did not make sense to use a stream driver for this design.
ReadFile and WriteFile are actually rather inapplicable for doing much other
than, well, accessing file like lumps of data.
In the HID case the USB driver is simplified, 2 entry points and a callback
"phidpPreparsedData". Have a look at the samples,
WINCE600\PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\HID\CLIENTS\KBDHID\kbdhid.cpp
> 2. Is it possible to write a custom HID driver without the Platform
> Builder,
> e.g. only with Visual Studio 2005 VC++?
If you have the SDK for the target device then this should be possible.
Actually you probably don't even need the SDK but you will need to toolchain
for the target CPU.
> 3. If VS2005 is ok, how can I debug the driver?
RETAILMSG works well enough. You can run the debugger over activesync if you
really want to do that. I've always had access to PB so this is not
something I have bothered with this scenario.
> 4. Is my custom HID driver an addon to the USBHID.dll or does it replace
> the
> USBHID.dll?
USBHID will load <your device>HID.dll when the settings in the registry
indicate that it should be loaded, i.e. when the entries matche the HID
device type. (it can get loaded without a match or manually too). It will be
like kbdhid.dll - look at that sample.
> 5. Which registry settings are necessary to load the "MyHidDrv.dll"?
> (Should
> only be loaded, if the HID device with our VendorID (e.g. 4711) has been
> connected)
http://msdn2.microsoft.com/en-us/library/aa925912.aspx
Admittedly that link is not much use. The class is '3' (for HID)
See the comment from the OpenClientRegKey function of the USBHID driver:
// Contains most of the logic to find and open the proper HID client key.
// The algorithm searches for the most specific vendor key of the form
// idVendor_idProduct_bcdDevice. Then its subkeys are searched for the most
// specific interface key of the form bInterface_bCollection. Then its
// subkeys are searched for the most specific top level collection key
// of the form UsagePage_Usage.
//
// The order of vendor precedence is described below.
//
// idVendor_idProduct_bcdDevice
// idVendor_idProduct
// idVendor
// Default
//
// The order of interface precedence is described below.
//
// bInterface_bCollection
// bInterface
// Default
//
// The order of TLC precedence is
//
// UsagePage_Usage
// UsagePage
// Default
//
// So the order of checking would be
// 1. idVendor_idProduct_bcdDevice\bInterface_bCollection\UsagePage_Usage
// 2. idVendor_idProduct_bcdDevice\bInterface_bCollection\UsagePage
// 3. idVendor_idProduct_bcdDevice\bInterface_bCollection\Default
// 4. idVendor_idProduct_bcdDevice\bInterface\UsagePage_Usage
// ...
// 7. idVendor_idProduct_bcdDevice\Default\UsagePage_Usage
// ...
// 10. idVendor_idProduct\bInterface_bCollection\UsagePage_Usage
// ...
// 42. Default\bInterface_bCollection\Default
// 43. Default\bInterface\UsagePage_Usage
// 44. Default\bInterface\UsagePage
// 45. Default\bInterface\Default
// 46. Default\Default\UsagePage_Usage
// 47. Default\Default\UsagePage
// 48. Default\Default\Default
> 6. How can I implement a Streaming-Interface with ReadFile() and
> WriteFile()
> to receive and send reports?
Memory mapped files would allow you to use your familiar read/write file
notion, there are lots of samples on the web.
See here for a simple overview: http://support.microsoft.com/kb/301108
Mein Luftkissenfahrzeug ist voller Aale!
Geoff
--
(sorry about my German, I'm English).
Tony Hedge
Wilson & Aspi Havewala (ISBN 0-201-61636-X) a useful guide. It deals
with CE3.0 and (I think) is out-of-print but still available second hand.
It has about 10 pages devoted to USB Driver development. I've never read
any of them, as I haven't need to do anything with USB, but it has about
6 chapters in all devoted to device drivers.
Hope this is useful. Good Luck.
Tony
B.Gottschalk
@Silver:
Your german is perfect!!!
I wanted to have a look at the file with the comment from the
OpenClientRegKey function of the USBHID driver, but I couldn't find it. Where
is it located?
RETAILMSG() uses the printf-function and I read that the embedded device can
send the debug-text via COM-Port to a terminal-appl. but our device doesn't.
What have I to do that this works via COM-Port?
Now I am using ::MessageBox() to show some debug-information and it works
well.
The file "MYHIDDRV.DLL" has to be in the "\windows"-folder of the
embedded-device.
The correct registry settings are:
[HKEY_LOCAL_MACHINE\Drivers\HID\LoadClients\Default\Default\<UsagePage>_<Usage>\MyHidDrv]
"DLL" = "MYHIDDRV.DLL"
"<UsagePage>" and "<Usage>" are placeholders for the corresponding values
which could be found in the "HID REPORT HEADER" of our device.
I found a link to a sample for a custom Windows CE HID driver:
see
"http://users.ece.gatech.edu/~hamblen/489X/F06PROJ/CypressHills_USB/Technicals.htm"
They use a Message-Queue (CreateMsgQueue() / WriteMsgQueue() /
ReadMsgQueue()) to transport the data between an application and the driver.
Now I have to decide if I should use a Message-Queue or the
Memory-Mapped-File approach to transport the data. Which one has got the
higher performance if there is a lot of data to be exchanged between the
PC-application and the HID-device?
@Tony:
I'll have a look at the book. Sounds good.
Thank you very much.
Silver
void OEMInitDebugSerial(void)
void OEMWriteDebugString(unsigned short *str)
void OEMWriteDebugByte(BYTE ucChar)
see here:
http://msdn2.microsoft.com/en-us/library/aa913477.aspx
I am not sure what you mean here:
> I wanted to have a look at the file with the comment from the
> OpenClientRegKey function of the USBHID driver, but I couldn't find it.
> Where
> is it located?
All of the USB stack lives under wince\public\common\oak\drivers\usb
Do you mean this file:
PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\HID\HIDCLASS\MDD\hidmdd.cpp
> Now I have to decide if I should use a Message-Queue or the
> Memory-Mapped-File approach to transport the data. Which one has got the
> higher performance if there is a lot of data to be exchanged between the
> PC-application and the HID-device?
A message queue will copy the data into the allocated buffer space of the
queue whereas a memory mapped file only maps a pointer to the same block of
memory. For large amounts of data this means a lot of copying for a message
queue. Thats said, you would possible still use a message queue to indicate
that data is waiting in the mem-mapped file.
Message queues are really simple though.
It all depends what a lot of data really means - a few KB/second is nothing,
even a few MB /sec on a fast CPU is very little - but bear in mind that you
will use more memory with a MMQ as there will be a copy in the queue as well
well as the original buffer.
Geoff
--
joan joan
I have the same problem, I need to connect a HID device to my WinCE 6.0 and read/write from VS.NEt C# but I don't know how. Please if you have found the solution let em know.
Thanks
Joan
>> On Monday, March 03, 2008 1:39 PM Silver wrote:
>> Many drivers are written as stream driver, but all they really use are
>> init/deinit and IOControls. There is so much going on in a USB stack that it
>> did not make sense to use a stream driver for this design.
>> ReadFile and WriteFile are actually rather inapplicable for doing much other
>> than, well, accessing file like lumps of data.
>>
>> In the HID case the USB driver is simplified, 2 entry points and a callback
>> "phidpPreparsedData". Have a look at the samples,
>> WINCE600\PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\HID\CLIENTS\KBDHID\kbdhid.cpp
>>
>> If you have the SDK for the target device then this should be possible.
>> Actually you probably don't even need the SDK but you will need to toolchain
>> for the target CPU.
>>
>> RETAILMSG works well enough. You can run the debugger over activesync if you
>> really want to do that. I've always had access to PB so this is not
>> something I have bothered with this scenario.
>>
>> USBHID will load <your device>HID.dll when the settings in the registry
>> indicate that it should be loaded, i.e. when the entries matche the HID
>> device type. (it can get loaded without a match or manually too). It will be
>> like kbdhid.dll - look at that sample.
>>
>> Memory mapped files would allow you to use your familiar read/write file
>> notion, there are lots of samples on the web.
>> See here for a simple overview: http://support.microsoft.com/kb/301108
>>
>> Mein Luftkissenfahrzeug ist voller Aale!
>> Geoff
>> --
>> (sorry about my German, I'm English).
>>> On Tuesday, March 04, 2008 4:59 AM Tony Hedge wrote:
>>> You might find "Building Powerful Platforms with Windows CE" by James Y
>>> Wilson & Aspi Havewala (ISBN 0-201-61636-X) a useful guide. It deals
>>> with CE3.0 and (I think) is out-of-print but still available second hand.
>>>
>>> It has about 10 pages devoted to USB Driver development. I've never read
>>> any of them, as I haven't need to do anything with USB, but it has about
>>> 6 chapters in all devoted to device drivers.
>>>
>>> Hope this is useful. Good Luck.
>>>
>>> Tony
>>>
>>> B.Gottschalk wrote:
>>>> On Thursday, March 06, 2008 4:32 AM BGottschal wrote:
>>>> Thank you very much.
>>>>
>>>> @Silver:
>>>> Your german is perfect!!!
>>>>
>>>> I wanted to have a look at the file with the comment from the
>>>> OpenClientRegKey function of the USBHID driver, but I couldn't find it. Where
>>>> is it located?
>>>>
>>>> RETAILMSG() uses the printf-function and I read that the embedded device can
>>>> send the debug-text via COM-Port to a terminal-appl. but our device doesn't.
>>>> What have I to do that this works via COM-Port?
>>>> Now I am using ::MessageBox() to show some debug-information and it works
>>>> well.
>>>>
>>>> The file "MYHIDDRV.DLL" has to be in the "\windows"-folder of the
>>>> embedded-device.
>>>>
>>>> The correct registry settings are:
>>>> [HKEY_LOCAL_MACHINE\Drivers\HID\LoadClients\Default\Default\<UsagePage>_<Usage>\MyHidDrv]
>>>> "DLL" = "MYHIDDRV.DLL"
>>>>
>>>> "<UsagePage>" and "<Usage>" are placeholders for the corresponding values
>>>> which could be found in the "HID REPORT HEADER" of our device.
>>>>
>>>>
>>>> I found a link to a sample for a custom Windows CE HID driver:
>>>> see
>>>> "http://users.ece.gatech.edu/~hamblen/489X/F06PROJ/CypressHills_USB/Technicals.htm"
>>>>
>>>> They use a Message-Queue (CreateMsgQueue() / WriteMsgQueue() /
>>>> ReadMsgQueue()) to transport the data between an application and the driver.
>>>>
>>>>
>>>>
>>>> Now I have to decide if I should use a Message-Queue or the
>>>> Memory-Mapped-File approach to transport the data. Which one has got the
>>>> higher performance if there is a lot of data to be exchanged between the
>>>> PC-application and the HID-device?
>>>>
>>>> @Tony:
>>>> I'll have a look at the book. Sounds good.
>>>>
>>>> Thank you very much.
>>>>> On Thursday, March 06, 2008 12:06 PM Silver wrote:
>>>>> RETAILMSG - you need to implement the function
>>>>>
>>>>> void OEMInitDebugSerial(void)
>>>>> void OEMWriteDebugString(unsigned short *str)
>>>>> void OEMWriteDebugByte(BYTE ucChar)
>>>>>
>>>>> see here:
>>>>> http://msdn2.microsoft.com/en-us/library/aa913477.aspx
>>>>>
>>>>> I am not sure what you mean here:
>>>>> All of the USB stack lives under wince\public\common\oak\drivers\usb
>>>>> Do you mean this file:
>>>>> PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\HID\HIDCLASS\MDD\hidmdd.cpp
>>>>>
>>>>> A message queue will copy the data into the allocated buffer space of the
>>>>> queue whereas a memory mapped file only maps a pointer to the same block of
>>>>> memory. For large amounts of data this means a lot of copying for a message
>>>>> queue. Thats said, you would possible still use a message queue to indicate
>>>>> that data is waiting in the mem-mapped file.
>>>>> Message queues are really simple though.
>>>>> It all depends what a lot of data really means - a few KB/second is nothing,
>>>>> even a few MB /sec on a fast CPU is very little - but bear in mind that you
>>>>> will use more memory with a MMQ as there will be a copy in the queue as well
>>>>> well as the original buffer.
>>>>>
>>>>>
>>>>> Geoff
>>>>> --
>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>> Book Review: Google Analytics
>>>>> http://www.eggheadcafe.com/tutorials/aspnet/a855a620-50a8-487c-9fac-b85f8fda2442/book-review-google-analytics.aspx
liangli...@gmail.com
liangli...@gmail.com
Hardware platform which has got an USB host controller. I have few questions like to ask about the HID driver,
1. Do I need find the connected device with function findfirstdevice with
guid as one of parameters?
2. Do I have to verify the connected device with product and vendor id?
3. The driver often calling PCHID_FUNCS, how does that work?, I can not find an example any where