filter above serial waits for special char

hello everyone,

have installed an upper filter above serial and want to let it listen fo=
r =

a special character.
this char will be send from a device to the com-port, where my filter is=
=

attached on.

in detail:
from an usermode app. a deviceIoControl - request is send to my filter.=

the dispatch-routine for this ioctl-request sends a char to the com-port=
=

via self-made irp (IoBuildAsynchronousFsdRequest, IoSetCompletionRoutine=
, =

IoCallDriver)... that works fine so far.
but, after that i need to listen for an answer from the connected device=
, =

which is a special character. after this char is identified, a next writ=
e =

with some buffer content has to start immediately.

my first idea was to set up a workerthread right after the write, which =
=

sends a synchronous read request down to serial and waits. then, the =

thread validates the content of the readbuffer and initiates the next =

write-op.

my question is, is this a realistic method? (this is my first experience=
=

in driver programming)
and, can such a construction react fast enough, that the delay btw. =

incoming answer and next write is physicaly below 6 ms ?

thanks for your answers

Ray
Tue May 25 18:09:19 CDT 2004

There's not really enough info here for me to say for sure. One comment
I will make, though, is that if you're counting on this special
character to "identify" your device, and you want to have your filter
installed all the time (because, say, you don't have a PnP ID or
something), I don't think that's a good idea. There are only 256
possible 8-bit values, and I'm sure all of them are used at some point
by some device.

Another comment is: what do you mean by "immediately"? Windows can
introduce nearly arbitrary delays. Any design that can't handle this
needs to be fixed with some kind of hardware buffering.

Sanni wrote:

> hello everyone,
>
> have installed an upper filter above serial and want to let it listen
> for a special character.
> this char will be send from a device to the com-port, where my filter
> is attached on.
>
> in detail:
> from an usermode app. a deviceIoControl - request is send to my filter.
> the dispatch-routine for this ioctl-request sends a char to the
> com-port via self-made irp (IoBuildAsynchronousFsdRequest,
> IoSetCompletionRoutine, IoCallDriver)... that works fine so far.
> but, after that i need to listen for an answer from the connected
> device, which is a special character. after this char is identified, a
> next write with some buffer content has to start immediately.
>
> my first idea was to set up a workerthread right after the write, which
> sends a synchronous read request down to serial and waits. then, the
> thread validates the content of the readbuffer and initiates the next
> write-op.
>
> my question is, is this a realistic method? (this is my first
> experience in driver programming)
> and, can such a construction react fast enough, that the delay btw.
> incoming answer and next write is physicaly below 6 ms ?
>
> thanks for your answers
>

Sanni
Tue May 25 23:27:01 CDT 2004

thanks for your comment.
you're right, there is no pnp id. it's a legacy device, originally =

designed for use with DOS several years ago. timing is not critical ther=
e. =

but now, software for this device has to be ported to win2000/xp. but th=
is =

is a soft-realtime environment, where you can't rely on exact timing. =

'think thats what you mean with arbitrary delays. the device has no =

precaution build-in in form of any hardware buffering.
my filter has only to listen for the char and react, if the user-mode ap=
p =

says him to do so via ioctl.

--------------
Am Tue, 25 May 2004 16:09:19 -0700 hat Ray Trent =

<rat@synaptics.com.spamblock> geschrieben:

> There's not really enough info here for me to say for sure. One commen=
t =

> I will make, though, is that if you're counting on this special =

> character to "identify" your device, and you want to have your filter =
=

> installed all the time (because, say, you don't have a PnP ID or =

> something), I don't think that's a good idea. There are only 256 =

> possible 8-bit values, and I'm sure all of them are used at some point=
=

> by some device.
>
> Another comment is: what do you mean by "immediately"? Windows can =

> introduce nearly arbitrary delays. Any design that can't handle this =

> needs to be fixed with some kind of hardware buffering.
>

Ray
Thu May 27 12:06:05 CDT 2004

I guess my question would then be: why do this in a driver at all? Why
not do it all from the app you're porting?

Sanni wrote:

> thanks for your comment.
> you're right, there is no pnp id. it's a legacy device, originally
> designed for use with DOS several years ago. timing is not critical
> there. but now, software for this device has to be ported to
> win2000/xp. but this is a soft-realtime environment, where you can't
> rely on exact timing. 'think thats what you mean with arbitrary delays.
> the device has no precaution build-in in form of any hardware buffering.
> my filter has only to listen for the char and react, if the user-mode
> app says him to do so via ioctl.
>
> --------------
> Am Tue, 25 May 2004 16:09:19 -0700 hat Ray Trent
> <rat@synaptics.com.spamblock> geschrieben:
>
>> There's not really enough info here for me to say for sure. One
>> comment I will make, though, is that if you're counting on this
>> special character to "identify" your device, and you want to have
>> your filter installed all the time (because, say, you don't have a
>> PnP ID or something), I don't think that's a good idea. There are
>> only 256 possible 8-bit values, and I'm sure all of them are used at
>> some point by some device.
>>
>> Another comment is: what do you mean by "immediately"? Windows can
>> introduce nearly arbitrary delays. Any design that can't handle this
>> needs to be fixed with some kind of hardware buffering.
>>
>
>

Sanni
Fri May 28 06:47:09 CDT 2004

right, thats been done already, but's not working. in some cases, the =

user-mode app (runs at highest priority level available) fails, because =
=

the reaction time is not short enough. so the idea was to move the =

reacting part into kernel-mode. and i'm the lucky one to write a driver =
=

for this issue.


Am Thu, 27 May 2004 10:06:05 -0700 hat Ray Trent =

<rat@synaptics.com.spamblock> geschrieben:

> I guess my question would then be: why do this in a driver at all? Why=
=

> not do it all from the app you're porting?
>

Doron
Fri May 28 11:32:48 CDT 2004

if you set a completion routine, you can process the results immediately and
issue another PIRP from the completion routine w/out synchronously blocking
any thread.

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.


"Sanni" <morphemerkenner@web.de> wrote in message
news:opr8kfi2utk2odb4@sanni...
hello everyone,

have installed an upper filter above serial and want to let it listen for
a special character.
this char will be send from a device to the com-port, where my filter is
attached on.

in detail:
from an usermode app. a deviceIoControl - request is send to my filter.
the dispatch-routine for this ioctl-request sends a char to the com-port
via self-made irp (IoBuildAsynchronousFsdRequest, IoSetCompletionRoutine,
IoCallDriver)... that works fine so far.
but, after that i need to listen for an answer from the connected device,
which is a special character. after this char is identified, a next write
with some buffer content has to start immediately.

my first idea was to set up a workerthread right after the write, which
sends a synchronous read request down to serial and waits. then, the
thread validates the content of the readbuffer and initiates the next
write-op.

my question is, is this a realistic method? (this is my first experience
in driver programming)
and, can such a construction react fast enough, that the delay btw.
incoming answer and next write is physicaly below 6 ms ?

thanks for your answers

Alexander
Fri May 28 11:51:39 CDT 2004

Will use of APC (ReadFileEx) give faster response than waiting on an event?
Does running of APC affect thread priority?

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:eJp1qFNREHA.2468@tk2msftngp13.phx.gbl...
> if you set a completion routine, you can process the results immediately
and
> issue another PIRP from the completion routine w/out synchronously
blocking
> any thread.
>
> 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.
>
>
> "Sanni" <morphemerkenner@web.de> wrote in message
> news:opr8kfi2utk2odb4@sanni...
> hello everyone,
>
> have installed an upper filter above serial and want to let it listen for
> a special character.
> this char will be send from a device to the com-port, where my filter is
> attached on.
>
> in detail:
> from an usermode app. a deviceIoControl - request is send to my filter.
> the dispatch-routine for this ioctl-request sends a char to the com-port
> via self-made irp (IoBuildAsynchronousFsdRequest, IoSetCompletionRoutine,
> IoCallDriver)... that works fine so far.
> but, after that i need to listen for an answer from the connected device,
> which is a special character. after this char is identified, a next write
> with some buffer content has to start immediately.
>
> my first idea was to set up a workerthread right after the write, which
> sends a synchronous read request down to serial and waits. then, the
> thread validates the content of the readbuffer and initiates the next
> write-op.
>
> my question is, is this a realistic method? (this is my first experience
> in driver programming)
> and, can such a construction react fast enough, that the delay btw.
> incoming answer and next write is physicaly below 6 ms ?
>
> thanks for your answers
>
>

Doron
Fri May 28 17:15:32 CDT 2004

he would have to be in a waitable state for APCs to be delivered (something
like SleepEx being called). I don't know if that is overkill for this
situation or not. i think whatever timing issues are present here, being in
the kernel, in the end, is not going to affect anything. the problem will
be present b/c of limitations of hw, not sw.

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.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:etz3QQNREHA.3720@TK2MSFTNGP09.phx.gbl...
> Will use of APC (ReadFileEx) give faster response than waiting on an
event?
> Does running of APC affect thread priority?
>
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:eJp1qFNREHA.2468@tk2msftngp13.phx.gbl...
> > if you set a completion routine, you can process the results immediately
> and
> > issue another PIRP from the completion routine w/out synchronously
> blocking
> > any thread.
> >
> > 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.
> >
> >
> > "Sanni" <morphemerkenner@web.de> wrote in message
> > news:opr8kfi2utk2odb4@sanni...
> > hello everyone,
> >
> > have installed an upper filter above serial and want to let it listen
for
> > a special character.
> > this char will be send from a device to the com-port, where my filter is
> > attached on.
> >
> > in detail:
> > from an usermode app. a deviceIoControl - request is send to my filter.
> > the dispatch-routine for this ioctl-request sends a char to the com-port
> > via self-made irp (IoBuildAsynchronousFsdRequest,
IoSetCompletionRoutine,
> > IoCallDriver)... that works fine so far.
> > but, after that i need to listen for an answer from the connected
device,
> > which is a special character. after this char is identified, a next
write
> > with some buffer content has to start immediately.
> >
> > my first idea was to set up a workerthread right after the write, which
> > sends a synchronous read request down to serial and waits. then, the
> > thread validates the content of the readbuffer and initiates the next
> > write-op.
> >
> > my question is, is this a realistic method? (this is my first experience
> > in driver programming)
> > and, can such a construction react fast enough, that the delay btw.
> > incoming answer and next write is physicaly below 6 ms ?
> >
> > thanks for your answers
> >
> >
>
>

Alexander
Fri May 28 21:32:55 CDT 2004

In the kernel he can use DPCs/completion routines to get the data going and
have somewhat better latencies because of that.

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:OIKgJFQREHA.628@TK2MSFTNGP11.phx.gbl...
> he would have to be in a waitable state for APCs to be delivered
(something
> like SleepEx being called). I don't know if that is overkill for this
> situation or not. i think whatever timing issues are present here, being
in
> the kernel, in the end, is not going to affect anything. the problem will
> be present b/c of limitations of hw, not sw.
>
> 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.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:etz3QQNREHA.3720@TK2MSFTNGP09.phx.gbl...
> > Will use of APC (ReadFileEx) give faster response than waiting on an
> event?
> > Does running of APC affect thread priority?
> >
> > "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> > news:eJp1qFNREHA.2468@tk2msftngp13.phx.gbl...
> > > if you set a completion routine, you can process the results
immediately
> > and
> > > issue another PIRP from the completion routine w/out synchronously
> > blocking
> > > any thread.
> > >
> > > 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.
> > >
> > >
> > > "Sanni" <morphemerkenner@web.de> wrote in message
> > > news:opr8kfi2utk2odb4@sanni...
> > > hello everyone,
> > >
> > > have installed an upper filter above serial and want to let it listen
> for
> > > a special character.
> > > this char will be send from a device to the com-port, where my filter
is
> > > attached on.
> > >
> > > in detail:
> > > from an usermode app. a deviceIoControl - request is send to my
filter.
> > > the dispatch-routine for this ioctl-request sends a char to the
com-port
> > > via self-made irp (IoBuildAsynchronousFsdRequest,
> IoSetCompletionRoutine,
> > > IoCallDriver)... that works fine so far.
> > > but, after that i need to listen for an answer from the connected
> device,
> > > which is a special character. after this char is identified, a next
> write
> > > with some buffer content has to start immediately.
> > >
> > > my first idea was to set up a workerthread right after the write,
which
> > > sends a synchronous read request down to serial and waits. then, the
> > > thread validates the content of the readbuffer and initiates the next
> > > write-op.
> > >
> > > my question is, is this a realistic method? (this is my first
experience
> > > in driver programming)
> > > and, can such a construction react fast enough, that the delay btw.
> > > incoming answer and next write is physicaly below 6 ms ?
> > >
> > > thanks for your answers
> > >
> > >
> >
> >
>
>

Sanni
Sat May 29 08:15:26 CDT 2004

interesting discussion.
in first time i thought to have the reaction done within the completion =
=

routine.
the problem is, that, if i synchronously call a IRP_MJ_READ - operation,=
=

this will block the calling routine (ioctl-dispatch). but parallel i nee=
d =

this routine to fill up my internal buffer. so i thought about an =

asynchronous IRP_MJ_READ call. but does this implicate polling?

one question is simply, how the operation behave.
when i call IRP_MJ_READ, will the operation only come back if an =

read-operation was successful (means a char was received)? or does the o=
p =

come back and says...oh, there was nothing in my fifo or yes, here is wh=
at =

i got? i don't want to poll serial for a received char, i want to react =
if =

there was a char received (like an isr would do in serial).
this was my intention to insert a workerthread, that waits for an Rx-eve=
nt =

of serial.


thanks for your comments


Am Fri, 28 May 2004 19:32:55 -0700 hat Alexander Grigoriev =

<alegr@earthlink.net> geschrieben:

> In the kernel he can use DPCs/completion routines to get the data goin=
g =

> and
> have somewhat better latencies because of that.

Doron
Sat May 29 13:09:13 CDT 2004

it will return if there is data in the fifo. you can flush the fifo before
starting your timing sequence. sending a response in the completion routine
can be thought of polling, but it is asynchronous polling b/c you are not
blocking a thread to receive data, you are processing the polled data when
it arrives. when you send the request from the completion routine, it
cannot be a synchronous request. you must set a completion routine and
process this next request asynchronously as well.

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.


"Sanni" <morphemerkenner@web.de> wrote in message
news:opr8ri30usk2odb4@sanni...
interesting discussion.
in first time i thought to have the reaction done within the completion
routine.
the problem is, that, if i synchronously call a IRP_MJ_READ - operation,
this will block the calling routine (ioctl-dispatch). but parallel i need
this routine to fill up my internal buffer. so i thought about an
asynchronous IRP_MJ_READ call. but does this implicate polling?

one question is simply, how the operation behave.
when i call IRP_MJ_READ, will the operation only come back if an
read-operation was successful (means a char was received)? or does the op
come back and says...oh, there was nothing in my fifo or yes, here is what
i got? i don't want to poll serial for a received char, i want to react if
there was a char received (like an isr would do in serial).
this was my intention to insert a workerthread, that waits for an Rx-event
of serial.


thanks for your comments


Am Fri, 28 May 2004 19:32:55 -0700 hat Alexander Grigoriev
<alegr@earthlink.net> geschrieben:

> In the kernel he can use DPCs/completion routines to get the data going
> and
> have somewhat better latencies because of that.

Doron
Sat May 29 13:10:20 CDT 2004

the performance increases here are minimal here IMO, esp w/regard to serial
port which is not the fastest piece of hw in the world. It is a common
misconception that just b/c you are in kernel mode, things are faster. Not
necessarily so, it just means you can crash the machine more readily in most
cases :).

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.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%23J6CSVSREHA.1396@TK2MSFTNGP12.phx.gbl...
> In the kernel he can use DPCs/completion routines to get the data going
and
> have somewhat better latencies because of that.
>
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:OIKgJFQREHA.628@TK2MSFTNGP11.phx.gbl...
> > he would have to be in a waitable state for APCs to be delivered
> (something
> > like SleepEx being called). I don't know if that is overkill for this
> > situation or not. i think whatever timing issues are present here,
being
> in
> > the kernel, in the end, is not going to affect anything. the problem
will
> > be present b/c of limitations of hw, not sw.
> >
> > 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.
> >
> >
> > "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> > news:etz3QQNREHA.3720@TK2MSFTNGP09.phx.gbl...
> > > Will use of APC (ReadFileEx) give faster response than waiting on an
> > event?
> > > Does running of APC affect thread priority?
> > >
> > > "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> > > news:eJp1qFNREHA.2468@tk2msftngp13.phx.gbl...
> > > > if you set a completion routine, you can process the results
> immediately
> > > and
> > > > issue another PIRP from the completion routine w/out synchronously
> > > blocking
> > > > any thread.
> > > >
> > > > 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.
> > > >
> > > >
> > > > "Sanni" <morphemerkenner@web.de> wrote in message
> > > > news:opr8kfi2utk2odb4@sanni...
> > > > hello everyone,
> > > >
> > > > have installed an upper filter above serial and want to let it
listen
> > for
> > > > a special character.
> > > > this char will be send from a device to the com-port, where my
filter
> is
> > > > attached on.
> > > >
> > > > in detail:
> > > > from an usermode app. a deviceIoControl - request is send to my
> filter.
> > > > the dispatch-routine for this ioctl-request sends a char to the
> com-port
> > > > via self-made irp (IoBuildAsynchronousFsdRequest,
> > IoSetCompletionRoutine,
> > > > IoCallDriver)... that works fine so far.
> > > > but, after that i need to listen for an answer from the connected
> > device,
> > > > which is a special character. after this char is identified, a next
> > write
> > > > with some buffer content has to start immediately.
> > > >
> > > > my first idea was to set up a workerthread right after the write,
> which
> > > > sends a synchronous read request down to serial and waits. then, the
> > > > thread validates the content of the readbuffer and initiates the
next
> > > > write-op.
> > > >
> > > > my question is, is this a realistic method? (this is my first
> experience
> > > > in driver programming)
> > > > and, can such a construction react fast enough, that the delay btw.
> > > > incoming answer and next write is physicaly below 6 ms ?
> > > >
> > > > thanks for your answers
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Sanni
Tue Jun 01 04:06:59 CDT 2004

after your suggestions i implemented some testroutines.
now i'm happy because it works.

two small problems i encountered now.
1.
i started an asynch.IRP_MJ_READ and did not know where to find the char.=

within my completion-routine for this call i looked at the readbuffer i =
=

gave to IoBuildAsyn...
and i looked at Irp->AssociatedIrp.SystemBuffer.
but, there's no sign of the char, that came over the line.
in my readbuffer nothing changed, and in the sysbuffer sits a 255.

2.
my completion-routine for mentioned READ-call seems to be called in a =

non-deterministic way.
whenever i make a READ-call, my finger sends back a char from terminal a=
t =

the remote-machine.
sometimes i see a prompt reaction (debugview) from completion-routine, b=
ut =

sometimes there's nothing. even if i hack in the terminal like a fool. =

only when i send a return through the line i get immediate response for =
=

sure.


thanks

Am Sat, 29 May 2004 11:09:13 -0700 hat Doron Holan [MS] =

<doronh@nospam.microsoft.com> geschrieben:

> it will return if there is data in the fifo. you can flush the fifo =

> before
> starting your timing sequence. sending a response in the completion =

> routine
> can be thought of polling, but it is asynchronous polling b/c you are =
not
> blocking a thread to receive data, you are processing the polled data =
=

> when
> it arrives. when you send the request from the completion routine, it=

> cannot be a synchronous request. you must set a completion routine an=
d
> process this next request asynchronously as well.
>
> d
>

Sanni
Tue Jun 01 08:06:44 CDT 2004

have found a solution by myself.
filling out the dcb structure in my testapp. solved both problems so far=
.




Am Tue, 01 Jun 2004 11:06:59 +0200 hat Sanni <morphemerkenner@web.de> =

geschrieben:

> after your suggestions i implemented some testroutines.
> now i'm happy because it works.
>
> two small problems i encountered now.
> 1.
> i started an asynch.IRP_MJ_READ and did not know where to find the cha=
r.
> within my completion-routine for this call i looked at the readbuffer =
i =

> gave to IoBuildAsyn...
> and i looked at Irp->AssociatedIrp.SystemBuffer.
> but, there's no sign of the char, that came over the line.
> in my readbuffer nothing changed, and in the sysbuffer sits a 255.
>
> 2.
> my completion-routine for mentioned READ-call seems to be called in a =
=

> non-deterministic way.
> whenever i make a READ-call, my finger sends back a char from terminal=
=

> at the remote-machine.
> sometimes i see a prompt reaction (debugview) from completion-routine,=
=

> but sometimes there's nothing. even if i hack in the terminal like a =

> fool. only when i send a return through the line i get immediate =

> response for sure.
>
>
> thanks