Hi all,
I want to write a Virtual COM-port driver so a USB-port will look/act/behave like a COM-port.
Anyone know where to find information about how to do it? Or can somebody give me some ideas about how to start?
you have to implement all ioctls defined for com port devices which are well documented in WDK. and have to convert those requests into appropriate usb request either using control transfer for port configuration and use bulk requests for data transfer using com port. you can refer examples of usb bulk transfer which will be your base driver and add ioctls support for com port in that driver will be best option…
Ok, so you mean that I should implement the driver as a USB-driver and add the IOCTL:s for COM ports?
So I guess I still have to implement the entire PrepareHardware, AddDevice and so on for USB?
Thank you so much for helping me!
ya if you want to move data on usb 2 serial converter.
yes ofcourse you have to implement some minor modification or add the code for initializing your port with default configuration ,etc in adddevice routine.
Adddecvice and other general usb driver interfaces are already implemented in that sample driver (using WDM kernel mode driver) so may be your so many code implementation time can be reduced.
Ok, good. I have allready looked, copied and modified the osrusbfx2 kmdf exampel so it fits for my device. (Or is it some other exampel you recommends?)
So I will get right on with implementing the IOCTLS for COM ports now.
Thank you for the help and I guess I will be back in a couple of days to ask more. 
and one more question:
When creating a Device Interface in my driver, which GUID should I use in this case?
status = WdfDeviceCreateDeviceInterface(device, &GUID_DEVINTERFACE_XXX, NULL);
My USB-device is a modem but the driver should be a virtual com port driver, so should I use the GUID_DEVINTERFACE_MODEM or the GUID_DEVINTERFACE_COMPORT (or perhaps something else??)
i didn’t work with kmdf framework but i did it using bulkusb sample provided in ddk of xp.,vista.
you can also do it using kmdf framework also.
Use the comport dev interface. The modem dev interface will be enabled by modem.system as an upper filter via your ing. Also, read the serial sample. It will give you the entire ioctl interface you need to implement.
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@hotmail.com
Sent: July 01, 2010 2:41 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual COM-port driver
and one more question:
When creating a Device Interface in my driver, which GUID should I use in this case?
status = WdfDeviceCreateDeviceInterface(device, &GUID_DEVINTERFACE_XXX, NULL);
My USB-device is a modem but the driver should be a virtual com port driver, so should I use the GUID_DEVINTERFACE_MODEM or the GUID_DEVINTERFACE_COMPORT (or perhaps something else??)
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Ok, thanks for the help Doron.
I have already started to look at the serial example but I still have to understand how to implement them in a appropiate way for USB. I guess I will ask more questions before this is over.
Any reason your hardware is not cdc compliant and thus just use usbser.sys?
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@hotmail.com
Sent: July 01, 2010 7:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual COM-port driver
Ok, thanks for the help Doron.
I have already started to look at the serial example but I still have to understand how to implement them in a appropiate way for USB. I guess I will ask more questions before this is over.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
xxxxx@hotmail.com wrote:
Ok, so you mean that I should implement the driver as a USB-driver and add the IOCTL:s for COM ports?
So I guess I still have to implement the entire PrepareHardware, AddDevice and so on for USB?
What is your hardware? With few exceptions, the companies that
manufacture USB/Serial converters provide fully functional drivers with
their chips.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I don’t understand some of this yet.
So please correct me if I’m wrong.
I should implement a USB-driver as a base for this driver. So I have to do everything needed for a usb, (addDevice, prepareHardware and so on). So I should use both interfaces my device uses and open the three pipes as the example (“osrusbfx2 kmdf”) does? (like a CDC my device has two interfaces, one with the control end-point and one with the two bulk end-points).
Then I should initialize a COM-port too in addDevice?
And then implement all the serial IOCTL:s there are (like in the example “serial”) but modifiy them so it works with usb instead and use the control pipe for COM-port settings and use the bulk pipes for data transfers?
Is this right or do I missunderstand it totaly?
u understand the right way…
I understand? I can’t believe it, it must be the first time ever! 
Thanks again Paras!
Once and again, I just tries to straighting things out in my head, so please let me know if I have missunderstand things. (And I know this might be annoying for you guys how completely understand this things, so I’m sorry for your inconvenience).
Like I see this driver, it’s a kind of three part driver. The first part is the USB device driver. This part handles all things needed for initialization and communication for the usb hardware. Like opening pipes and creating usb requests and sending them to the device over the usb connection.
The second part is the virtual COM-port part. It initialize everything needed for the virtual COM-port. This part gets all the incomming “COM-port request”.
The third part is the USB-to-COM converter. It gets all the COM-port requests and converts it to appropiate USB request by handling all the serial IOCTL:s and converting them to correct USB requests.
Is this a correct way to look at it?
My next questions is the serial ioctl converting. For example, the IOCTL_SERIAL_SET_BAUD_RATE. The hardware talk over USB, so does it even care about baud rate? Should I just remove the request and return success when recieving such a request?
I guess this can be specific for the hardware, but my hardware is a modem talking to the PC over USB. It is implementet to follow the CDC standard.
Thanks again for all help I got from you guys!
xxxxx@hotmail.com wrote:
Like I see this driver, it’s a kind of three part driver. The first part is the USB device driver. This part handles all things needed for initialization and communication for the usb hardware. Like opening pipes and creating usb requests and sending them to the device over the usb connection.
The second part is the virtual COM-port part. It initialize everything needed for the virtual COM-port. This part gets all the incomming “COM-port request”.
The third part is the USB-to-COM converter. It gets all the COM-port requests and converts it to appropiate USB request by handling all the serial IOCTL:s and converting them to correct USB requests.
Is this a correct way to look at it?
Sort of, but I’m not convinced this is really the right mental model.
Remember that this is all one driver.
Every driver has an upper interface (which it exposes to clients) and a
lower interface (which gets closer to hardware), and the two interfaces
are usually quite different. The job of a driver is to convert from the
upper interface to the lower interface, and it’s really not much more
than that. In the case of usbaudio.sys, for example, the upper
interface is the kernel streaming API. The lower interface is USB requests.
So, the normal operation of a driver is to initialize the lower
interface, and then respond to requests on the upper interface by
passing things through to the lower interface.
In your case, the upper interface is the COM port interface, including
ioctls. The lower interface is USB requests. To perform your function,
you have to fetch descriptors and initialize data structures at startup
time (before the upper interface goes live), and then respond to COM
port requests by creating URBs.
My next questions is the serial ioctl converting. For example, the IOCTL_SERIAL_SET_BAUD_RATE. The hardware talk over USB, so does it even care about baud rate? Should I just remove the request and return success when recieving such a request?
You have to know that. If you can’t change your baud rate, then you can
just respond with success. Remember that your client believes it is
talking to an RS-232 port. You have to keep up that charade.
I guess this can be specific for the hardware, but my hardware is a modem talking to the PC over USB. It is implementet to follow the CDC standard.
Then, again, why are you not using the standard usbser.sys driver?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
wrote in message news:xxxxx@ntdev…
…
> My next questions is the serial ioctl converting. For example, the
> IOCTL_SERIAL_SET_BAUD_RATE. The hardware talk over USB, so does it even
> care about baud rate? Should I just remove the request and return success
> when recieving such a request?
>
Yes, baud rate is not relevant.
Just same as for PCI modem that emulates UART registers but does not have a
serial interface behind of it. The modem data transfer protocol has flow
control
and ensures back pressure on the sender.
If the sender does not obey this protocol and keeps writing - it’s got a
problem.
– pa
About 10 year go I realized driver which you asked for soft modem…
I don’t remember all details but you have to:
-
Support ALL COM port interface. Y have to support all COM port functionality which you see in given DDK driver. I had started from driver from Driver::Works which written more better on C++. Unfortunately that product died, but try, if you find it. COM port interface is not changed last years…
-
To be COM port, you have to realize UART functionality. If you need is going through WHQL, you have to support all, including bound rate, bits etc.
-
To be modem, you have to simulate ATx modem command set and create apportionment INF file.
It is not easy job. I wish you success…
Regards,
Michael Grabelkovsky.
Driver::works, while a nice idea, was a bug ridden product. Do not go out and seek it, there are reasons it died.
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@hotmail.com
Sent: July 03, 2010 7:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual COM-port driver
About 10 year go I realized driver which you asked for soft modem…
I don’t remember all details but you have to:
1. Support ALL COM port interface. Y have to support all COM port functionality which you see in given DDK driver. I had started from driver from Driver::Works which written more better on C++. Unfortunately that product died, but try, if you find it. COM port interface is not changed last years…
2. To be COM port, you have to realize UART functionality. If you need is going through WHQL, you have to support all, including bound rate, bits etc.
3. To be modem, you have to simulate ATx modem command set and create apportionment INF file.
It is not easy job. I wish you success…
Regards,
Michael Grabelkovsky.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>given DDK driver. I had started from driver from Driver::Works which written more better on C++.
Unfortunately that product died, but try, if you find it.
This product was amazingly buggy, and now is actually replaced by KMDF.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com