Prev: How To: CStatubar panel Right-align text
Next: MFC app - add multithreading?
From: Joseph M. Newcomer on 3 Apr 2010 18:33
[shameless plug: I teach a device driver course through www.traininghott.com and it is a
starting point. After that, it gets more complex. OSR (www.osr.com) offers advanced
courses and USB-based courses (ours concentrates on PCI cards). Their file system driver
course requires a ton of experience writing device drivers (they cover our entire 1-week
course as a "refresher" on Monday. Then it gets REALLY hard)] Buy their sample USB
board, and download their driver source and study it. (They sell the boards at cost).

[second shameless plug: Dekker & Newcomer, Developing Windows NT Device Drivers
(Addison-Wesley)] In addition, Walter Oney's books from Microsoft Press, Tony Mason and
Peter Viscarola's book [purchasable from www.osr.com], the new Microsoft Press book on the
Kernel Mode Driver Foundation. ]

Subscribe to the OSR newsletter (it's frree!). Lurk on the OSR newsgroups (like ntdev).
joe

On Fri, 2 Apr 2010 11:35:01 -0700, nexolite <nexolite(a)discussions.microsoft.com> wrote:

>Hi... What work/study path you recommend to become a good device driver
>programmer ?
>
>Thanks
>
>"Joseph M. Newcomer" wrote:
>
>> You have not actually said what you mean by "USB interface". For example, if the device
>> comes with a USB cable to connected it, it MUST have a WIndows driver that connects to
>> that device. In which case, you will know the device name to open and you will open that
>> device and use ReadFile and WriteFile to talk to it, in accordance with the interface
>> specs.
>>
>> If you are working for the company that produces the equipment, be aware that they will
>> have to write a Device Driver tha communicates to this device. This can be done as a
>> kernel-mode driver using KMDF, or a user-mode driver using UMDF, but the important part
>> here is that it must be design and written, which means if they have not already started
>> this, it ain't gonna happen in the "near future" for any conventional interpretation of
>> "near". Otherwise, the device will come with a programming manual that describes how to
>> talk to it. The fact that the communication to the device takes place over USB is
>> completely irrelevant to you, the application programmer. And if it doesn't come with a
>> device driver, they have not delivered a "product", but what we traditionally call a
>> "paperweight".
>>
>> I know a few device driver programmers who are USB experts (I don't count myself among
>> them) if you need assistance.
>> joe
>>
>> On Wed, 31 Mar 2010 10:10:01 -0500, TomChapman <TomChapman12(a)gmail.com> wrote:
>>
>> >Many of my programs communicate with equipment using serial COM port
>> >interfaces or network TCP interfaces.
>> >
>> >In the near future I will need to communicate with a new piece of
>> >equipment that uses a USB interface. I don't know any specifics yet. I
>> >don't know if there is a SDK for this piece of equipment.
>> >
>> >How do I communicate with USB? Is there a library or a book anyone can
>> >recommend? Any comments would be appreciated.
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>> .
>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: RFOG on 4 Apr 2010 06:06
I know.

As always, thanks for the aclaration! :-)

On Sat, 03 Apr 2010 17:26:38 -0500, Joseph M. Newcomer
<newcomer(a)flounder.com> wrote:

>It is not uncommon that a manufacture will smooth over the ugliness of the low-level API
>interface by providing a library (most commonly as a DLL), but the key here is that the
>DLL is not the device driver; it is an INTERFACE to the device driver!
>
>In my driver course, I describe to my students how to trade off the coding decisions
>between what has to go into the driver and what can move up to the DLL, and how the
>engineering decisions are made as to where code should go.
>
>But without the actual device driver, the DLL cannot do anything. Unless the device is
>designed to be HID-compliant, in which case the DLL disguises the ugliness of the
>interface details (for example, the use of DeviceIoControl is reasonably ugly to explain
>to application programmers. Note that the serial port driver does NOT implment APIs such
>as GetCommState, SetCommTimeouts, etc.; these are APIs that appear in a DLL (I forget
>which one) that generate reasonably ugly DeviceIoControl calls to the actual device
>driver, which has to support something like 44 different IOCTL codes for DeviceIoControl.
> joe
>
>On Fri, 02 Apr 2010 21:13:21 +0200, RFOG <no(a)mail.com> wrote:
>
>>Sigh!
>>
>>Joseph: the MFR offers the DLL that interact with the driver that
>>interact with the hardware. Then the MFR ofers a DLL that does the job
>>(appart from a driver, of course).
>>
>>Do you want a sample? Here:
>>http://www.heber.co.uk/downloads.php?page=downloads_xspin
>****
>It sounds like this is a HID-compliant device because it has to do with gaming. Or this
>is a library for interfacing to generic HID-compliant devices. In this case, Microsoft
>has written the device driver, and you are using a library that intefaces to it.
> joe
>****
>>
>>The board only has a bootloader that waits the windows/linux driver to
>>inject the firmware.
>>
>>
>>On Fri, 02 Apr 2010 12:47:12 -0500, Joseph M. Newcomer
>><newcomer(a)flounder.com> wrote:
>>
>>>It is a common misconcpetion that a simple DLL will supply the necessary connectivity to a
>>>USB device. This is not true. Only a device driver (kernel or user mode) will work, and
>>>these are complex beasts that require extremely careful design and implementation.
>>>
>>>No "patches" to Windows are required. and "a DLL" won't do the job!
>>> joe
>>>
>>>On Wed, 31 Mar 2010 21:32:30 +0300, RFOG <no(a)mail.com> wrote:
>>>
>>>>Sometimes those devices use a virtual COM, that is, a driver that converts
>>>>a USB port to a RS232 port and then it is used as one normal serial port.
>>>>Others that uses direct USB stuff, as David has said, normally offers a
>>>>DLL or a more easy way to work with. However each mfr. uses his own
>>>>approach. Some offers a DLL, some patches normal windows
>>>>CreateFile/ReadFile/WriteFile. But most common is use a DLL or a
>>>>USB-to-Serial driver.
>>>>
>>>>On Wed, 31 Mar 2010 18:10:01 +0300, TomChapman <TomChapman12(a)gmail.com>
>>>>wrote:
>>>>
>>>>> Many of my programs communicate with equipment using serial COM port
>>>>> interfaces or network TCP interfaces.
>>>>>
>>>>> In the near future I will need to communicate with a new piece of
>>>>> equipment that uses a USB interface. I don't know any specifics yet. I
>>>>> don't know if there is a SDK for this piece of equipment.
>>>>>
>>>>> How do I communicate with USB? Is there a library or a book anyone can
>>>>> recommend? Any comments would be appreciated.
>>>Joseph M. Newcomer [MVP]
>>>email: newcomer(a)flounder.com
>>>Web: http://www.flounder.com
>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>>ÿþM
>Joseph M. Newcomer [MVP]
>email: newcomer(a)flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
ÿþM
First  |  Prev  | 
Pages: 1 2 3
Prev: How To: CStatubar panel Right-align text
Next: MFC app - add multithreading?