If you want your device to resemble a serial port, it *must* implement all
the DeviceIoControl functions of a serial port! Note that some may be
inappropriate (e.g., if your device does not have a variable data rate, you
will “ignore” the set-baud-rate requests, and I put “ignore” in quotes
because you have to (a) IoCompleteRequest the IRP with a STATUS_SUCCESS (b)
retain the dummy baud rate value to be returned on a query, *even though it
has no meaning*. Otherwise, a program like HyperTerminal assumes that if
anything fails (for example, setting inter-character timeouts) that the port
is non-responsive, and it will probably close it and report an error.
If you want to *add* functionality, you are free to do so, providing that
failure to use that functionality does not affect the ability of your
COM-like port to actually work in a COM-port context, which apparently is
what you want to do.
You have suggested (but not actually said) that you have changed some of the
functionality. You have to *honor* all the requests that come down, even if
it means maintaining useless information to be returned on a query for that
information. You can’t simply reject something you don’t support if it is
one of the (I think 44, if I recall correctly) required IOCTLs for a serial
port.
You have also not suggested that you wrote a little test program that opened
the port, wrote something to it, and closed the port (or read something from
it, or just tried to open and close it). Instead, you go to full-blown
HyperTerminal, which probably expects *perfect* conformance with the
required IOCTLs. I suggest building small test programs and testing a
feature at a time; your testing methodology of testing all features
simultaneously is not a good testing strategy.
You can’t implement it “pretty much exactly”, you have no choice but to
implement it *exactly*. At least at the upper edge, where the IRPs are
coming through; what you actually do to the device is your business, as long
as the interface remains identical at the upper edge of the driver.
I actually had a client that had a serial port filter driver that talked
across the network to another machine and used its serial port, sort of a
“redirector”. The filename was of the form
\.COMn\192.168.168.4\COMm
Where COMn was the local serial port and COMm was the serial port to use on
the remote machine, shown here as 192.168.168.4. I had nothing to do with
the coding of this, in fact, all I had to do was interface my application to
it. They bought it from someone else. We used it to connect a serial port
device to the remote computer’s serial port. In this case, it sent the
baud-rate-change as an OOB packet to the remote machine, which would change
the baud rate on its local serial port. But that was six years ago, and
I’ve forgotten who the vendor was (the machines on which I was running it
are long since retired).
But your description lacks critical information about what you changed, how
you changed it, etc., making it impossible guess what is going wrong.
Write a little test program. All it does is open and close the device.
Then try each feature of the serial port, one at a time, carefully checking
for what is returned. When you have a test harness that lets you test every
single feature individually, and you have shown that you have tested every
feature individually, ONLY THEN do you throw some massive program like
HyperTerminal at it. Using DbgPrint or WPP or even (and this is not a good
idea) event log output to trace what is going on, particularly for all error
returns, would be crucial.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.se
Sent: Tuesday, August 03, 2010 9:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Serial driver development
Hey!
This is the first time a develops a windows driver so of course I have some
major problems. I hope you guys can help me.
I have been looking at the serial example in WinDDK 7600.16385.1 and I want
to make my own serial driver for a COM-port device I have.
The serial example is really helpfull but I can’t get it work. I have
implemented pretty much exactly like the example for DriverEntry,
SerialEvtDeviceAdd, SerialPrepareHardware and so on. What I have
changed/about to changes is the IOCTLS in ioctl.c because I want to do it a
bit different so it fits for my device.
When I install my driver everything works fine and my device pops up in the
DeviceManager and if I check the settings in DeviceManager, it says that it
uses COM3.
But the problem is that when I tries to talk to the device through COM3 (or
any other COMx) it just tells me that the Port isn’t open. (Btw, I use
hyperterminal for communicate with the device).
So my question is, does anyone know what initialization that must be done
for open a COM-port? Or can it be my “not yet finished” ioctl part that is
the problem, so if I finish it, can it work?
Like a said, this is my first driver and I don’t really understand all this
yet.
Thanks in advance!
// Greger
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
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.