Adaption of serial.sys for sub-millisecond timing resolution on serial port

Yellow...

Some guidance is required, please.

In order to provide sub-millisecond timing information along with incoming
serial data recieved at the comm port, I am adapting the serial.sys driver
to insert three bytes of timing information, snapped from a call to
KeGetSystemTimer.

How is it done in my application when I open up the comms port, to specify
that MY serial.sys, let me call it serialex.sys is utilised?
In other words, how is the driver specified in the call to OpenFile?

My current understanding is that ...
no actually, I really have no idea.

Comments, please?
Thanks
Luke

 

there is no way other then to make sure that if you are opening "COM1" that
your driver is assigned to service "COM1". If you are not exposing COM port
name (which it sounds like you might not b/c it is a custom interface), then
have your driver expose a custom device name \Device\MySerialEx0 and an
appropriately similar DOS name, that way you will know it is your driver and
not serial.sys

d

 

Use KeQueryPerformanceCounter instead.

 

If that is the case, then how is it done to select to which physical COM
port my driver attaches?
Do I need to build individual drivers for COM1 and COM2 and every other COM
port, each with the IO base address changed?
What mechanism permits me to simply build one new serialex.sys and to then
specify to which specific physical port my driver should attach?
How is the original serial.sys unloaded from the required COM port before I
attach my driver?

Thanks
Luke

 

you install your driver on each instance that matches the hwID (probably
*pnp0501), see devcon.exe. resource assigment changes do not matter, it is
still the same device instance.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

 

Testing millisecond timing empirically

I guess it depends on what you want to do but there's a subtle difference between accuracy and precision. Even using APIs you'll be millisecond precise but not accurate. That is, units of milliseconds but not that you're reading the timer at the right time.

Plus if you're trying to time say a visual display to the millisecond then you're likely to be out of luck. PC's, Macs and Linux will all have similar problems as they use the same hardware. Even RTOS systems won't help you all that much as soon as you interact with a standard TFT or keyboard.

For some background on the issues take a look at our website and read about our Black Box ToolKit which helps users achieve millisecond timing accuracy in experimental work. Just Google Black Box ToolKit.