Bluetooth has no baud rate, partity, etc. Setting one is irrelevent, and I
still think that the problem lies in the driver not properly handling these
settings.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com
silverfox said:You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in the
middle of a driver call? Is the driver left in a bad state? Can the OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the display?
It's not so simple to 'just' terminate an application.
The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the .NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.
Paul T.
On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're trying
to
use them (I can pretty much guarantee they used native code to test).
My
guess is that the serial classes are trying to set up some parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to test
what
happens when you try to change it. Good examples might be baud rate,
flow
control, parity, stop bits, timeouts, etc.
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.comActually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem. I
would have thought that the Quit button on the OS-generated dialog box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things fail
that seems like a bug in the OS to me. But maybe that's just me.So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find that
such an obvious application as serial communications was not tested at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.
You don't know much about operating systems.
Ok, I admit it.
I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:
System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()
Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:
serialPort.Write(msg)
I
OK, I've looked through the old messages and I don't see what the
characteristics of 'msg' are that you are passing to that Write method. You
might try, if msg is a large amount of data, sending something simple, like
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
seeing if the other end receives that.
Paul T.
You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in the
middle of a driver call? Is the driver left in a bad state? Can the OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the display?
It's not so simple to 'just' terminate an application.
The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the .NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.
Paul T.
On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?
Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're trying
to
use them (I can pretty much guarantee they used native code to test).
My
guess is that the serial classes are trying to set up some parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to test
what
happens when you try to change it. Good examples might be baud rate,
flow
control, parity, stop bits, timeouts, etc.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com
Actually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem. I
would have thought that the Quit button on the OS-generated dialog box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things fail
that seems like a bug in the OS to me. But maybe that's just me.
So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find that
such an obvious application as serial communications was not tested at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.
You don't know much about operating systems.Ok, I admit it.I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:
I
silverfox said:OK, I've looked through the old messages and I don't see what the
characteristics of 'msg' are that you are passing to that Write method.
You
might try, if msg is a large amount of data, sending something simple,
like
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
seeing if the other end receives that.
Paul T.
On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in
the
middle of a driver call? Is the driver left in a bad state? Can the
OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the
display?
It's not so simple to 'just' terminate an application.The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the
.NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.Paul T.news:[email protected]...
On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you
saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're
trying
to
use them (I can pretty much guarantee they used native code to
test).
My
guess is that the serial classes are trying to set up some
parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to
test
what
happens when you try to change it. Good examples might be baud
rate,
flow
control, parity, stop bits, timeouts, etc.
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.comActually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem.
I
would have thought that the Quit button on the OS-generated dialog
box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things
fail
that seems like a bug in the OS to me. But maybe that's just me.So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find
that
such an obvious application as serial communications was not tested
at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.You don't know much about operating systems.Ok, I admit it.I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:
I
I am in fact sending three ascii characters plus a CR.
Hi,
With BT, the actual port speed is arbitrary. You can use anything that is
supported, with exactly the same result. You would want to use 8 data bits,
with no parity. If the code hangs on Output... I'm confused.
CFSerialIO.dll (from my homepage) use SerialPort.Output(somemessage) syntax.
The SerialPort object in Visual Studio uses SerialPort.Write(somemessage)
syntax.
I have never seen a "hang," though the Output method in my dll is a blocking
method. Thus, if data are not accepted by the serial driver (control must
be returned from the WriteFile API call), then what you are seeing is what
I'd expect. I guess. Windows CE does not support Overlapped IO, so any
non-blocking call to WriteFile requires extra effort -- and I've never seen
the need. If this is the situation, there would seem to be some underlying
mechanism that is the source of the trouble. Just, IMO, from the outside
looking in.
Dick
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.
See my replies to your email.
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.