custom IOCTL in serial.sys

NTDEV
21

I need to read the LSR because I’m used to work directly with
microcontrollers, in which I have allways access to whole registers
space, so I can work at highest possible speeds in serial transmissions.

In this case, I want to control the state of the 9th bit in order to
implement a kind of 485 bus. If the 9th bit is a ‘1’, the byte will be
an address, and if it’s a ‘0’, it will be data.

The problem appears when I change the state of the 9th bit from ‘1’ to
‘0’ (when I have sent the 1st byte, indicating the address of the
peripheral, and I send the 2nd byte, which is a data byte). I do it
before the shift register has finished sending the whole byte, so I
‘corrupt’ the state of the 9th bit, setting it to ‘0’ too soon.

That’s why I need to know the state of this shift register, I must
ensure that it’s empty in order to be able to change the 9th bit state,
and I can only get this info by reading the LSR.

Now, I wonder how is it possible that I have to implement a custom IOCTL
for getting a kind of info that I think that is as basic as other infos
that you can get with yet implemented IOCTLs.

It’s a little worring that I can get the full power of a simple
microcontroller running at 16MHz, but I can’t do it at all because my
PC, which runs at least 100 times faster, doesn’t allow to.

What would you suggest, putting a delay between the address and the
first data byte? If I can, I won’t do that.

En/na Ray Trent ha escrit:

Oh, and by the way OP, why do you think you need to read the LSR? That’s
usually an extremely accurate sign of a poorly designed serial device.

Doron Holan wrote:

> Of course, the next set of questions comes up. What if I plug the
> device into the other com port on the machine? What if I plug the
> device into a usb -> serial adapter which you cannot rewrite the driver
> for? What if I plug it into a multi port serial card?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
> Sent: Thursday, April 14, 2005 11:48 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] custom IOCTL in serial.sys
>
> Hi,
>
> Don’t worry, Loren, I had the same confusion when I first looked for the
>
> way to read LSR.
>
> Doron, it’s for motherboard UART, so I will replace the driver for
> just one serial port, as you suggested me.
>
> Thanks again for your help, I’ll tell you when I get it work.
>
>
> En/na Loren Wilton ha escrit:
>
>
>>>> Elena, the OP, just wanted to read the LINE STATUS REGISTER on the
>
>
> UART.
>
>>> Since I’m pretty sure that you can get these values with one of the
>
>
> user
>
>>
>> Duh, never mind! I was thinking of the MSR not the LSR.
>> There is indeed no function to read the LSR.
>>
>> Loren
>>
>>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

22

I see 2 alternatives:

  • change to 8th bit signaling instead of 9th bit.
    This restricts raw data to be 7-bit, which can be compensated by
    escape chars or bit-shifts to become 8-bit again. ( overhead is
    application dependent).But, all other peers need to be changed too(BAD!).

  • Use an external IO-gateway.(Built a device with one of the mentioned
    16 Mhz pics that has two serial ports. This device could translate
    into a protocol that you could use with a windows application.)

Fiddling inside the DDKs serial.sys sources, to do what you want will be
difficult, given the 'non-realtime' nature of windows.

Norbert.

"A positive attitude will not solve all your problems, but it will
annoy enough people to make it worth the effort. - Herm Albright"
---- snip ----

23

Interesting Elena:

(1) Are you changing the parity on a per character basis to use this 0 / 1,
9 th bit signalling?
(2) Are you changing the parity only when the device changes?
(3) You indeed need the the THR empty if you are doing this. If I
understand you correctly.
(4) If you are always send two bytes - one for the device and one for the
data you develop an IOCTL that does this too. If indeed you are using the
parity to signal device verses data.
Sincerely;
Michael Jones

“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
> I see 2 alternatives:
>
> - change to 8th bit signaling instead of 9th bit.
> This restricts raw data to be 7-bit, which can be compensated by
> escape chars or bit-shifts to become 8-bit again. ( overhead is
> application dependent).But, all other peers need to be changed
too(BAD!).
>
> - Use an external IO-gateway.(Built a device with one of the mentioned
> 16 Mhz pics that has two serial ports. This device could translate
> into a protocol that you could use with a windows application.)
>
> Fiddling inside the DDKs serial.sys sources, to do what you want will be
> difficult, given the ‘non-realtime’ nature of windows.
>
>
> Norbert.
> --------
> “A positive attitude will not solve all your problems, but it will
> annoy enough people to make it worth the effort. - Herm Albright”
> ---- snip ----
>
>
>

24

Michael,

(1) What do you mean when you say “on per character basis”? My sequence is:
1.- Set 9th bit to ‘1’
2.- Send Address byte
3.- Set 9th bit to ‘0’
4.- Send n Command & Data bytes
5.- Wait for answer of the device asked / addressed

(3) You are right, I need the THR empty. That’s why I read the LSR.
(4) I don’t understand your question.

Thanks

En/na Michael Jones ha escrit:

Interesting Elena:

(1) Are you changing the parity on a per character basis to use this 0 / 1,
9 th bit signalling?
(2) Are you changing the parity only when the device changes?
(3) You indeed need the the THR empty if you are doing this. If I
understand you correctly.
(4) If you are always send two bytes - one for the device and one for the
data you develop an IOCTL that does this too. If indeed you are using the
parity to signal device verses data.
Sincerely;
Michael Jones

“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
>
>>I see 2 alternatives:
>>
>>- change to 8th bit signaling instead of 9th bit.
>> This restricts raw data to be 7-bit, which can be compensated by
>> escape chars or bit-shifts to become 8-bit again. ( overhead is
>> application dependent).But, all other peers need to be changed
>
> too(BAD!).
>
>>- Use an external IO-gateway.(Built a device with one of the mentioned
>> 16 Mhz pics that has two serial ports. This device could translate
>> into a protocol that you could use with a windows application.)
>>
>>Fiddling inside the DDKs serial.sys sources, to do what you want will be
>>difficult, given the ‘non-realtime’ nature of windows.
>>
>>
>>Norbert.
>>--------
>>“A positive attitude will not solve all your problems, but it will
>>annoy enough people to make it worth the effort. - Herm Albright”
>>---- snip ----
>>
>>
>>
>
>
>
>

25

Hi elena:

Thanks for the reply. The reason I am asking is that you have 5, 6, 7, 8
data bits per byte. When talk of the 9 bit I am confused. If you are
assuming 1 start bit and 8 data bits then the 9 bit would be the “last” data
bit in the 8 data bits. Is that what you mean.

When talking stop bit I was forgetting about the start bit and was think you
manipulated the stop bit then. This is indeed incorrect.

Yes and thanks for being patient with me.

Sincerely;
William Michael Jones “Mike”

“elena nito” wrote in message news:xxxxx@ntdev…
> Michael,
>
> (1) What do you mean when you say “on per character basis”? My sequence
is:
> 1.- Set 9th bit to ‘1’
> 2.- Send Address byte
> 3.- Set 9th bit to ‘0’
> 4.- Send n Command & Data bytes
> 5.- Wait for answer of the device asked / addressed
>
> (3) You are right, I need the THR empty. That’s why I read the LSR.
> (4) I don’t understand your question.
>
> Thanks
>
>
> En/na Michael Jones ha escrit:
> > Interesting Elena:
> >
> > (1) Are you changing the parity on a per character basis to use this 0 /
1,
> > 9 th bit signalling?
> > (2) Are you changing the parity only when the device changes?
> > (3) You indeed need the the THR empty if you are doing this. If I
> > understand you correctly.
> > (4) If you are always send two bytes - one for the device and one for
the
> > data you develop an IOCTL that does this too. If indeed you are using
the
> > parity to signal device verses data.
> > Sincerely;
> > Michael Jones
> >
> >
> > “Norbert Kawulski” wrote in message
news:xxxxx@ntdev…
> >
> >>I see 2 alternatives:
> >>
> >>- change to 8th bit signaling instead of 9th bit.
> >> This restricts raw data to be 7-bit, which can be compensated by
> >> escape chars or bit-shifts to become 8-bit again. ( overhead is
> >> application dependent).But, all other peers need to be changed
> >
> > too(BAD!).
> >
> >>- Use an external IO-gateway.(Built a device with one of the mentioned
> >> 16 Mhz pics that has two serial ports. This device could translate
> >> into a protocol that you could use with a windows application.)
> >>
> >>Fiddling inside the DDKs serial.sys sources, to do what you want will be
> >>difficult, given the ‘non-realtime’ nature of windows.
> >>
> >>
> >>Norbert.
> >>--------
> >>“A positive attitude will not solve all your problems, but it will
> >>annoy enough people to make it worth the effort. - Herm Albright”
> >>---- snip ----
> >>
> >>
> >>
> >
> >
> >
> >
>

26

From xxxxx@lists.osr.com <> on mercoled? 20 aprile 2005
22.06:

Hi elena:

Thanks for the reply. The reason I am asking is that you have 5, 6,
7, 8 data bits per byte. When talk of the 9 bit I am confused. If
you are assuming 1 start bit and 8 data bits then the 9 bit would be
the “last” data bit in the 8 data bits. Is that what you mean.

Remember that the serial controller can be programmed to send also a
parity bit before the stop bit(s). So if parity is enabled and the
number
of data bits to be sent per byte is set to 8, 9 bits + 1 Start bit +
1/1,5/2 Stop bit(s) are effectively sent.
The parity bit can be programmed to be Odd or Even parity (the value
is computed automatically by the controller) of fixed (Mark or Space).
What Elena wants do do is to program it to Mark before transmitting
the “address” byte and to Space before transmitting any “data” byte;
she needs to know when the transmit shift register is empty (from the
LSR) since if she sets the parity bit to Space when the address byte
has not yet been completely sent, the parity bit will be set to Space
for the address byte also.

For Elena: assuming that the only way to solve your problem is to re-
place the standard serial.sys with a customized one, I would suggest
a different approach, avoiding to implement a custom IOCTL for reading
the LSR. You should instead let the customized driver know some way
when a byte to be sent is an “address”, and modify the write code path
to handle this case inside the driver itself. This should avoid to the
application a tight loop of LSR reads (making the custom LSR-Read IOCTL
return only when the tx shift register is empty doesn’t really solve
the problem, since your app will receive back control with an unpre-
dictable delay)

Carlo

27

What confuses me is that the 485 spec demands 8N1, so, you don’t
have the flexibility of using the 9th bit for anything but
parity. Or am I misreading the document ?

Alberto.

----- Original Message -----
From: “Carlo Andreoli - Numerica Progetti”

To: “Windows System Software Devs Interest List”

Sent: Thursday, April 21, 2005 3:34 AM
Subject: RE: [ntdev] custom IOCTL in serial.sys

From xxxxx@lists.osr.com <> on mercoledì 20 aprile
2005
22.06:

> Hi elena:
>
> Thanks for the reply. The reason I am asking is that you have
> 5, 6,
> 7, 8 data bits per byte. When talk of the 9 bit I am confused.
> If
> you are assuming 1 start bit and 8 data bits then the 9 bit
> would be
> the “last” data bit in the 8 data bits. Is that what you
> mean.
>

Remember that the serial controller can be programmed to send
also a
parity bit before the stop bit(s). So if parity is enabled and
the
number
of data bits to be sent per byte is set to 8, 9 bits + 1 Start
bit +
1/1,5/2 Stop bit(s) are effectively sent.
The parity bit can be programmed to be Odd or Even parity (the
value
is computed automatically by the controller) of fixed (Mark or
Space).
What Elena wants do do is to program it to Mark before
transmitting
the “address” byte and to Space before transmitting any “data”
byte;
she needs to know when the transmit shift register is empty
(from the
LSR) since if she sets the parity bit to Space when the address
byte
has not yet been completely sent, the parity bit will be set to
Space
for the address byte also.

For Elena: assuming that the only way to solve your problem is
to re-
place the standard serial.sys with a customized one, I would
suggest
a different approach, avoiding to implement a custom IOCTL for
reading
the LSR. You should instead let the customized driver know some
way
when a byte to be sent is an “address”, and modify the write
code path
to handle this case inside the driver itself. This should avoid
to the
application a tight loop of LSR reads (making the custom
LSR-Read IOCTL
return only when the tx shift register is empty doesn’t really
solve
the problem, since your app will receive back control with an
unpre-
dictable delay)

Carlo

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

28

From xxxxx@lists.osr.com <> on gioved? 21 aprile 2005
14.10:

What confuses me is that the 485 spec demands 8N1, so, you don’t
have the flexibility of using the 9th bit for anything but
parity. Or am I misreading the document ?

I’ve not the 485 spec at hand, but if it demands 8N1 then the parity
bit is not used (N), so only 8 bits + start + stop(s) are transmitted

Carlo

29

Thanks, Carlo Andreoli, for the 9 bit explaination. I understand better.

One way.
(1) I think that elena could write an IOCTL that will take the parameters of
a Command byte, n data bytes for this Command, and say a count of the Data
bytes. Then within this modified Serial driver with this IOCTL she can wait
for the THR to be emty when programing the Command byte and rest of the Data
then can just sent. That she is not looping in her code for the THR to be
empty.

Second way!!!
(2) There is an Event for the THR to be empty that elena could set from her
application. She could send the Command Byte, wait on this event again,
Send the n Data bytes, Wait on this event again. That way she does not need
to change the serial driver at all. The event is SERIAL_EV_TXEMPTY. You
use the IOCTL_SERIAL_SET_WAIT_MASK to use this technique.

Sincerely;
William Michael Jones “Mike”

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> What confuses me is that the 485 spec demands 8N1, so, you don’t
> have the flexibility of using the 9th bit for anything but
> parity. Or am I misreading the document ?
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Carlo Andreoli - Numerica Progetti”
>
> To: “Windows System Software Devs Interest List”
>
> Sent: Thursday, April 21, 2005 3:34 AM
> Subject: RE: [ntdev] custom IOCTL in serial.sys
>
>
> From xxxxx@lists.osr.com <> on mercoledì 20 aprile
> 2005
> 22.06:
>
> > Hi elena:
> >
> > Thanks for the reply. The reason I am asking is that you have
> > 5, 6,
> > 7, 8 data bits per byte. When talk of the 9 bit I am confused.
> > If
> > you are assuming 1 start bit and 8 data bits then the 9 bit
> > would be
> > the “last” data bit in the 8 data bits. Is that what you
> > mean.
> >
>
> Remember that the serial controller can be programmed to send
> also a
> parity bit before the stop bit(s). So if parity is enabled and
> the
> number
> of data bits to be sent per byte is set to 8, 9 bits + 1 Start
> bit +
> 1/1,5/2 Stop bit(s) are effectively sent.
> The parity bit can be programmed to be Odd or Even parity (the
> value
> is computed automatically by the controller) of fixed (Mark or
> Space).
> What Elena wants do do is to program it to Mark before
> transmitting
> the “address” byte and to Space before transmitting any “data”
> byte;
> she needs to know when the transmit shift register is empty
> (from the
> LSR) since if she sets the parity bit to Space when the address
> byte
> has not yet been completely sent, the parity bit will be set to
> Space
> for the address byte also.
>
> For Elena: assuming that the only way to solve your problem is
> to re-
> place the standard serial.sys with a customized one, I would
> suggest
> a different approach, avoiding to implement a custom IOCTL for
> reading
> the LSR. You should instead let the customized driver know some
> way
> when a byte to be sent is an “address”, and modify the write
> code path
> to handle this case inside the driver itself. This should avoid
> to the
> application a tight loop of LSR reads (making the custom
> LSR-Read IOCTL
> return only when the tx shift register is empty doesn’t really
> solve
> the problem, since your app will receive back control with an
> unpre-
> dictable delay)
>
> Carlo
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>

30

(1) Sorry I just checked the Serial.sys code in the DDK and number 2 is
wrong! SERIAL_EV_TXEMPTY is only that the queues are empty.

Sorry,
Mike Jones

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> Thanks, Carlo Andreoli, for the 9 bit explaination. I understand better.
>
> One way.
> (1) I think that elena could write an IOCTL that will take the parameters
of
> a Command byte, n data bytes for this Command, and say a count of the Data
> bytes. Then within this modified Serial driver with this IOCTL she can
wait
> for the THR to be emty when programing the Command byte and rest of the
Data
> then can just sent. That she is not looping in her code for the THR to be
> empty.
>
> Second way!!!
> (2) There is an Event for the THR to be empty that elena could set from
her
> application. She could send the Command Byte, wait on this event again,
> Send the n Data bytes, Wait on this event again. That way she does not
need
> to change the serial driver at all. The event is SERIAL_EV_TXEMPTY. You
> use the IOCTL_SERIAL_SET_WAIT_MASK to use this technique.
>
> Sincerely;
> William Michael Jones “Mike”
>
>
>
> “Alberto Moreira” wrote in message news:xxxxx@ntdev…
> > What confuses me is that the 485 spec demands 8N1, so, you don’t
> > have the flexibility of using the 9th bit for anything but
> > parity. Or am I misreading the document ?
> >
> > Alberto.
> >
> >
> > ----- Original Message -----
> > From: “Carlo Andreoli - Numerica Progetti”
> >
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Thursday, April 21, 2005 3:34 AM
> > Subject: RE: [ntdev] custom IOCTL in serial.sys
> >
> >
> > From xxxxx@lists.osr.com <> on mercoledì 20 aprile
> > 2005
> > 22.06:
> >
> > > Hi elena:
> > >
> > > Thanks for the reply. The reason I am asking is that you have
> > > 5, 6,
> > > 7, 8 data bits per byte. When talk of the 9 bit I am confused.
> > > If
> > > you are assuming 1 start bit and 8 data bits then the 9 bit
> > > would be
> > > the “last” data bit in the 8 data bits. Is that what you
> > > mean.
> > >
> >
> > Remember that the serial controller can be programmed to send
> > also a
> > parity bit before the stop bit(s). So if parity is enabled and
> > the
> > number
> > of data bits to be sent per byte is set to 8, 9 bits + 1 Start
> > bit +
> > 1/1,5/2 Stop bit(s) are effectively sent.
> > The parity bit can be programmed to be Odd or Even parity (the
> > value
> > is computed automatically by the controller) of fixed (Mark or
> > Space).
> > What Elena wants do do is to program it to Mark before
> > transmitting
> > the “address” byte and to Space before transmitting any “data”
> > byte;
> > she needs to know when the transmit shift register is empty
> > (from the
> > LSR) since if she sets the parity bit to Space when the address
> > byte
> > has not yet been completely sent, the parity bit will be set to
> > Space
> > for the address byte also.
> >
> > For Elena: assuming that the only way to solve your problem is
> > to re-
> > place the standard serial.sys with a customized one, I would
> > suggest
> > a different approach, avoiding to implement a custom IOCTL for
> > reading
> > the LSR. You should instead let the customized driver know some
> > way
> > when a byte to be sent is an “address”, and modify the write
> > code path
> > to handle this case inside the driver itself. This should avoid
> > to the
> > application a tight loop of LSR reads (making the custom
> > LSR-Read IOCTL
> > return only when the tx shift register is empty doesn’t really
> > solve
> > the problem, since your app will receive back control with an
> > unpre-
> > dictable delay)
> >
> > Carlo
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
>
>
>

31

From xxxxx@lists.osr.com <> on gioved? 21 aprile 2005
14.35:

Thanks, Carlo Andreoli, for the 9 bit explaination. I understand
better.

One way.
(1) I think that elena could write an IOCTL that will take the
parameters of a Command byte, n data bytes for this Command, and say
a count of the Data bytes. Then within this modified Serial driver
with this IOCTL she can wait for the THR to be emty when programing
the Command byte and rest of the Data then can just sent. That she is
not looping in her code for the THR to be empty.

This is quite similar to what I suggested

Second way!!!
(2) There is an Event for the THR to be empty that elena could set
from her application. She could send the Command Byte, wait on this
event again, Send the n Data bytes, Wait on this event again. That
way she does not need to change the serial driver at all. The event
is SERIAL_EV_TXEMPTY. You
use the IOCTL_SERIAL_SET_WAIT_MASK to use this technique.

This doesn’t work, since the SERIAL_EV_TXEMPTY event signals the driver
buffer empty condition (no more byes to be sent to the hardware control-
ler), and this happens well before the data has been effectly transmit-
ted: the old 8250s had a 2-byte tx buffer, so when the SERIAL_EV_TXEMPTY
event is signalled there are still one or two characters to be transmit-
ted, and reprogramming the parity bit from Mark to Space will affect
them
also. Modern 16550 controllers have a 16+ bytes hardware buffer, so the
situation is even worse from this point of view.
The SDK Comm interface docs are sometimes misleading and need to be sup-
plemented with a good hands on experience.

Carlo

32

Carlo,

you have understood perfectly my situation. I like the solution you give
me, but I think it’s a little difficult for me (remember I’m only a
begginner :)). By the other hand, the unpredictable delay thay you
mention isn’t very important, because I’ll be sure that the THR register
is empty whatever delay is produced. And this situation is done only
once per frame transmission, so the time I lose isn’t significant at all.

Thanks for your help.

Alberto,

the microcontroller I use has got a special mode which initially only
watches the state of the 9th bit. If it’s a ‘0’, the microcontroller
doesn’t read the 8 address bits. If it’s a ‘1’, then it looks at the 8
address bits, and compares them against a value I’ve set before.
If the value is the same, it consideres itself addressed, and then waits
for the other data bits. If it’s not the same value, it doesn’t do
anything but waiting for a new word with the 9th bit set to ‘1’
(indicating a new address byte recevied).
That’s a way of automatically addressing a chain of 485 devices without
any microcontroller program intervention.
Again, I agree with Carlo: I’m not sending a parity bit, I’m sending a
kind of control bit, which isn’t understood as parity.

Michael,

Don’t worry, I also had this problem. I tried many ways to solve my
problem before touching any line of driver code!!!

Thanks.

En/na Carlo Andreoli - Numerica Progetti ha escrit:

From xxxxx@lists.osr.com <> on giovedì 21 aprile 2005
14.35:

>Thanks, Carlo Andreoli, for the 9 bit explaination. I understand
>better.
>
>One way.
>(1) I think that elena could write an IOCTL that will take the
>parameters of a Command byte, n data bytes for this Command, and say
>a count of the Data bytes. Then within this modified Serial driver
>with this IOCTL she can wait for the THR to be emty when programing
>the Command byte and rest of the Data then can just sent. That she is
>not looping in her code for the THR to be empty.
>

This is quite similar to what I suggested

>Second way!!!
>(2) There is an Event for the THR to be empty that elena could set
>from her application. She could send the Command Byte, wait on this
>event again, Send the n Data bytes, Wait on this event again. That
>way she does not need to change the serial driver at all. The event
>is SERIAL_EV_TXEMPTY. You
>use the IOCTL_SERIAL_SET_WAIT_MASK to use this technique.
>

This doesn’t work, since the SERIAL_EV_TXEMPTY event signals the driver
buffer empty condition (no more byes to be sent to the hardware control-
ler), and this happens well before the data has been effectly transmit-
ted: the old 8250s had a 2-byte tx buffer, so when the SERIAL_EV_TXEMPTY
event is signalled there are still one or two characters to be transmit-
ted, and reprogramming the parity bit from Mark to Space will affect
them
also. Modern 16550 controllers have a 16+ bytes hardware buffer, so the
situation is even worse from this point of view.
The SDK Comm interface docs are sometimes misleading and need to be sup-
plemented with a good hands on experience.

Carlo

33

From xxxxx@lists.osr.com <> on gioved? 21 aprile 2005
16.53:

Carlo,

you have understood perfectly my situation. I like the solution you
give me, but I think it’s a little difficult for me (remember I’m
only a begginner :)). By the other hand, the unpredictable delay thay
you mention isn’t very important, because I’ll be sure that the THR
register is empty whatever delay is produced. And this situation is
done only once per frame transmission, so the time I lose isn’t
significant at all.

Thanks for your help.

Elena,

the delay could be up to several msecs (depending on CPU speed and
system current load). If you can live with this, why not simply put
a wait in your app after sending the “address” byte, and wait before
setting the parity to Space and sending the “data” bytes? This way
you have no need to use a custom serial.sys. Notice that if you send
the “address” first and then wait before sending the data bytes, the
time to wait to be sure that the address has been completely sent
does not depend from the serial controller hardware tx buffer size,
since you have only one character to send. The wait value so depends
only from the serial line baud rate (about 1 msec at 9600 baud, less
for higher speeds). Notice anyway that a simple Sleep(), although al-
lowing a wait value in msecs, can effectively wait more than the spe-
cified wait interval, depending on the system timer granularity and
system current load; this can impact the total frame transmission
time (more severely if your frames are short)

Carlo

34

>the delay could be up to several msecs (depending on CPU speed and

system current load). If you can live with this, why not simply put
a wait in your app after sending the “address” byte, and wait before

Serial port is async. By definition. Pauses between bytes can be arbitrary. Any
serail-attached hardware designed without this in mind is a bad idea.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com