Serial legacy device KMDF driver

[Matthias]

Hello,

I need to develop a tool which allows for communication with a real-time bus
system over RS-232. The system sends data telegrams in 1 milisecond intervals
which need to be acknowledged by an ACK-telegram before the next data
telegram can be sent. The serial interface adapter does not support PnP
specification.

Currently, as I am new to Windows driver development, I am looking for a
starting point to dig into: either to implement a filter driver on top of
serial.sys or to implement a function driver which will be enumerated by
serenum.sys?

The goal is to provide a transparent and reliable service to the user mode
application which should just be able to communicate with the real-time
system via CreateFile, WriteFile Windows API functions.

Thank you.
Matthias

[Doron Holan [MSFT]]

why not just use serial.sys as is? is your device plugging into an existing
COM port or does it have its own connection via PCI or ISA?

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"Matthias" <Matt...@discussions.microsoft.com> wrote in message
news:A03355AD-F097-4728...@microsoft.com...

[Matthias]

Hello Doron,

yes, the device is connected to an existing COM port. The reason for
implementing a kernel mode driver is the timing issue, as user mode polling
can not guarantee such a fast response time, so, to my understanding, only an
interrupt based approach could be used.

I need to read a telegram from the UART, perform some CRC checking, etc. and
generate and acknowledgement byte and send it out to the UART within a time
frame of 1 milisecond.

So, the question is: Where to place the code for the aforementioned data
reading and ACK sending. I could imagine the following points to hook into:

1. The UART ISR in serial.sys - "dirty hacking" solution which I don't like.
2. Filter driver on top of serial.sys?
3. Function device driver on top of serenum.sys?
4. Any other approach which I don't see yet?

Thanks for your time.

Matthias
"Doron Holan [MSFT]" wrote:

> .
>

[Doron Holan [MSFT]]

a filter on top of serial.sys is not going to be any faster than something
in user mode. just because you are running in kernel mode does not mean you
run faster or have higher priority in scheduling. if you have a strict 1 ms
window I would suggest taking the serial driver and compiling your own
version with a different name. that way you can control what the ISR does
and have more control ... BUT, I don't think your device is something that
windows can support even if you do this. Windows is not an RTOS and there
are no guarantees that your ISR will be delivered in a timely manner and you
can easily exceed the 1 ms window in which you need to process the data

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"Matthias" <Matt...@discussions.microsoft.com> wrote in message

news:56BB07E2-B98F-4EC3...@microsoft.com...

[scorbin]

If you've got a strict 1ms requirement you may be able to accomplish
this with Windows Embedded paired with something like IntervalZero's
real-time extensions. I haven't personally used their product, but I
recently ran across it and my curiosity has grown lately.

I don't know about your requirements but you could also look into a
linux based solution that uses the real-time patches by Ingo Molnar.
I believe they've been included in kernels >= 2.8.16. Although
naturally you probably won't find much help going that direction in
these newsgroups ;)