System.IO.Ports.SerialPort _sp = new System.IO.Ports.SerialPort("COM", 9600,
System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
the port name isn't written correctly. It should me "COM1" or some other number
Alex Mang wrote:
This is the way I am initializing the serial port object (actually, callingthe
10-Dec-09
This is the way I am initializing the serial port object (actually, calling
the constrctor):
System.IO.Ports.SerialPort _sp = new System.IO.Ports.SerialPort("COM", 9600,
System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
I did have a Exception class in the catch defined, but as stated previously,
there is very little information on the IOException (almost nothing on the
stacktrace - e.g.: even the message is IOException). I do not recall wether it
had a HResult inf. Once I will get back home, I will check it again.
Thanks for your support!
If anyone had a similar problem before, please do not hesitate to let me know!
:
Previous Posts In This Thread:
COM port .Open() problem, in C#, CF 2.0, WinCE 6.0 R3
So I am using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
have the following problem:
When I try opening any COM port on the devices, i get an IOException
(obviously, there is no message on the exception). However, the most
interesting (as in odd) thing is that putting the .Open method alone in a
try/catch, I was able to use the .Write method on the serialPort object AND
connecting a display to the COM port, I could see that:
1. the port was open
2. i can write on the port crrectly
Did anyone ever had such a problem?
The oddest thing is that the exact same application works perfectly on
another image, same devices (indeed, as far as i remember, the other image is
a R2 image!).
Best regards,
Alex
Your explanation does not really give much to go on, but my guess is that
Your explanation does not really give much to go on, but my guess is that you
tried to open the port twice. The second time fails, but the port is still
open because you opened it the first time, so reads and writes work fine.
Paul T.
:
I think I agree with Paul.
I think I agree with Paul. I have not seen this, so without code to view, we
are playing a guessing game.
Perhaps you can simply test the .IsOpen() method to see if, in fact, the
port has been opened and not closed, earlier?
Dick
--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage:
www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.
Sorry, but I can only strongly disagree.
Sorry, but I can only strongly disagree.
If you would like, I could even share a code snippet of the app, since it is a
test app only.
Anyway, to sum everything up, the code is something like:
1. void Form_Load(object sender, EventArgs e)
2. {
3. serialPort.Open();
4. serialPort.WriteLine("test");
5. serialPort.Close();
6. }
The code above, would raise the IOException. However, if i write the
following code instead, everuthing works fine (which is odd).
1. void Form_Load(object sender, EventArgs e)
2. {
3. try{
4. serialPort.Open();
5. }catch{}
6. serialPort.WriteLine("test");
7. serialPort.Close();
8. }
Again, I repeat from the last thread: the application works perfectly on an
older R2 image (so there is no extra-opening on the port; otherwise, the app
would not work on the second image either). Surely, there are several
differences between the two images I am nentioning. But my question is wether
I am forgetting a component, or maybe an environment variable?
:
No, you are not forgetting an environment variable.
No, you are not forgetting an environment variable. The code is a much better
way to show what is going on. We need to see the contents of the exception
that you are, presumably, catching in the second case shown. So, do not just
do:
catch {}
actually catch it and examine it in the debugger. At worst, you should be
able to get an HResult that corresponds to what the exception is trying to
tell you went wrong. That should be a good hint.
it is possible that you have built things wrong in some way, of course, but I
think that it is more-likely to be some improvement in the error checking of
framework or some change in the serial driver behavior causing the problem.
You're doing this with a *very* simple set of serial port parameters? 9600,
n, 8, 1, no handshake, no time-outs?
Paul T.
:
This is the way I am initializing the serial port object (actually, callingthe
This is the way I am initializing the serial port object (actually, calling
the constrctor):
System.IO.Ports.SerialPort _sp = new System.IO.Ports.SerialPort("COM", 9600,
System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
I did have a Exception class in the catch defined, but as stated previously,
there is very little information on the IOException (almost nothing on the
stacktrace - e.g.: even the message is IOException). I do not recall wether it
had a HResult inf. Once I will get back home, I will check it again.
Thanks for your support!
If anyone had a similar problem before, please do not hesitate to let me know!
:
Try it without the call to Close().
Try it without the call to Close(). It (IMO) always good practice to close
the port, only after all data have been sent.
This may, or may not, be the case -- here. That is, is the Open() causing
the exception?
BTW, exceptions that do not report details, usually, are caused by the
driver, not by code in the framework.
Dick
--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage:
www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.
The exception is caused by the .Open method.
The exception is caused by the .Open method.
I had indeed once another problem where the exception was just like this
one, with very little information regarding it, cause by a driver. However,
it is strange how (theoretically) having used the same BSP for the other
image, on which there is not any exception thrown...
Any suggestions?
Alex
:
Sorry, I do not have any suggestion.
Sorry, I do not have any suggestion. Open should not throw an error, unless
the port selected is unavailable. So, my best guess (still) is a driver
failure. I suppose that this might actually be caused by a hardware fault,
but I have not seen it.
Dick
--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage:
www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.
I have the same problem.
I have the same problem.
Hardware - PNA (JJ-connect2100wide) atlas4 with WinCE 6 (r2).
What I see is that most of GPS applications i tested on it are able to
detect GPS port as COM1
and work ok.
I am trying to build my own tiny GPS application with compact framework
3.5
And when I try to call
serialPort.open()
I have absolutely same exception. I make a lot of attempts opening
port as "COM1" as "COM1:" and "\\.\COM1:" e.t.c
No success.. Exception is the same..At least when port name is valid.
Attempts to open port with wrong name rise other exception.
More.. I found some other C# projects most of which are proven to work
ok on other devices..
All of them fail with the same exception.
Doesn't matter I got binary and run it on my PNA or I comple it
myself and run it in debug mode.
Always I get exception.
My conclusion was that problem is related to using .NETCF
As other software can work on the same port.
My guess is that .NET CF opens COM1 as debugging port
so it becomes unavailable for application.
I was able to find in registry some key defining
COM1 as "Debugging port for atlas4 board"
So I guess this is a reason..
The question is how to disable using COM1 as debugging port for .NET
CF applications?
te:
unless
iver
fault,
Your conclusion is invalid. Try a program not written using .NETCF!
Your conclusion is invalid. Try a program not written using .NETCF! That
will tell you it it is NETCF related.
This has NOTHING to do with .NETCF. If there is a serial debug port, that is
done at the OS level. You'll have to see if that is enabled and change the
OS, if so, to make it work.
Paul T.
Submitted via EggHeadCafe - Software Developer Portal of Choice
SAPI 5.1: Voice - Enabled Applications With VB
http://www.eggheadcafe.com/tutorial...ab58-90633f7ae7e4/sapi-51-voice--enabled.aspx
