Serial legacy device KMDF driver

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

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" <> wrote in message
news:A03355AD-F097-4728-A639-...
> 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

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:

> 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" <> wrote in message
> news:A03355AD-F097-4728-A639-...
> > 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
>
> .
>

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" <> wrote in message
news:56BB07E2-B98F-4EC3-B734-...
> 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:
>
>> 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" <> wrote in message
>> news:A03355AD-F097-4728-A639-...
>> > 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
>>
>> .
>>