Serial Port problems
Hi.
Running Imate SP5m with .NET CF 2.0 SP1
I have contacted Imate (on the side: poor support) who confirm that Raw/Serial IR access is possible and is on COM3. In the registry it says COM4. Anyway...
If I use the serial Port class to open COM4 and write to it, I have the issue where when we do a serialport.write("hi");, the application does nothing. it just hangs, no exceptions are thrown. It does not even get to serialPort.Close();
If I use the serial Port class to open COM3 and then write to it, I get an exception @ serialPort.Write("hi");:
at System.IO.Ports.SerialStream.WinIOError()
at System.IO.Ports.SerialStream.Write()
at System.IO.Ports.SerialPort.Write()
at SerialIrTests.Form1.mnuStart_Click()
at System.Windows.Forms.MenuItem.OnClick()
at System.Windows.Forms.Menu.ProcessMnuProc()
at System.Windows.Forms.Form.WnProc()
at System.Windows.Forms.Control._InternalWnProc()
at Microsoft.AGL.Forms.EVL.EnterMainLoop()
at System.Windows.Forms.Application.Run()
at SerialIrTests.Program.Main()
I have also been doing some low level P/Invoke stuff also however I get errors doing it this way - let's not get into what errors are given and stick to .NET
I can't remember exactly what happens on the MDA Vario, as its gone for repair.
What do I do? I've done so much research, banged my head against a wall (and no, it is not a fault of Microsoft but the hardware manufacturers of the device) - I am stuck.
Imate say that the device does support RAW/Serial IR access but I don't believe it as I get these errors. (Also against the law for providing invalid information!)
I also bought an MDA Vario PPC for this, to use serial port but I believe I will probably have the same issue, but cannot positively confirm this.
The code is simple:
| |
SerialPort theSerialPort =new SerialPort("COMPortHere");
theSerialPort.Open();
theSerialPort.Write("hi");
theSerialPort.Close();
|
Any ideas? Any advice, hints, tips, guidence is much appreciated and valued highly at this time.
Thanks!
Hello. I'll try to answer your questions and point you in the right direction.
 ahmedilyas wrote: |
| I have contacted Imate (on the side: poor support) who confirm that Raw/Serial IR access is possible and is on COM3. In the registry it says COM4. Anyway... |
|
This may be device specific. COM3 is the IR port on the devices I have access to.
| ahmedilyas wrote: |
| If I use the serial Port class to open COM4 and write to it, I have the issue where when we do a serialport.write("hi");, the application does nothing. it just hangs, no exceptions are thrown. It does not even get to serialPort.Close(); |
|
Try setting the SerialPort.WriteTimeout property. The default to this is -1, which never times out. This may explain the hanging you are experiencing.
| ahmedilyas wrote: |
| If I use the serial Port class to open COM3 and then write to it, I get an exception @ serialPort.Write("hi");: |
|
Quite possibly because your device's IR port already has COM3 open. If you want to use IR, check out the IrDA classes in the .NET Compact Framework documentation available online.
| ahmedilyas wrote: |
| What do I do? I've done so much research, banged my head against a wall (and no, it is not a fault of Microsoft but the hardware manufacturers of the device) - I am stuck. |
|
Let me know if these tips help. If not, post again and I'll see what I can do further.
Thanks Andrew, I greatly appreciate your time and reply! :-)
The thing is, I need access to RAW IR (non IRDA) to transmit beams to another source (IR)
As you have said:
Quite possibly because your device's IR port already has COM3 open |
|
this is of course very true, but if I do PInvoke for createfile, setdcb, escapeCommFunction and so on - the dcb values for COM3 are not set and does not allow me to set it, it returns false as if I do it with any other port, it allows me to set it.
Even if I continue on with the setdcb values with failing, escapeCommFunction also fails.
So not only am I doing things the .NET way but also PInvoking.
I actually remember that when we close the serialport when using COM3 (or COM4, cannot remember now but will recheck) it would throw an IOException - a blank IOException. This also happens sometimes when we write to the COM port (3/4) (just looked, I posted the stacktrace in my original post)
any ideas?
I haven't forgotten about you. I'm trying to get the hardware to try this out myself so I can help you through it.
no worries, I am interested in this and trust you and never thought you would forget ;-)
Thanks
Ok well,...
In my trials here, serial communication works fine, as long as the serial port is not already opened by the OS or another app. A generic WinIOError is thrown for me (like it is for you) in the case where it was already opened. Also in my experience, the IR port is always opened by the OS. I don't know if/how to switch that off, and I'm sure it varies between devices. If you can find the way to switch it off on the OS, then perhaps you can access the beam directly by COM port as you are trying to do.
Thanks for the response and your valuable time for testing/confirming this for me.
The thing is, I just have no idea how to switch it off (if it is open). Have you been able to achieve this and make the Serial Port open and written to without any IOExceptions?
As said, it says that COM4 is Raw/Serial IR but what could be opening it from the OS? If we use COM3 (IRDA) and I disable the option to now allow incoming beams, then I can open the port but of course I get the same IOException.
So pretty much this is not achievable on the device due to perhaps some device ROM settings?
I obviously want to do things the proper (Microsoft) way however I have no idea what could be causing it to be open (COM3 or 4, whichever)
I don't want to mess up your thread but I have a very similar problem, however with slight differences. Maybe we can get tips from each other's posts.
I am trying to communicate via RS232. The receiving device as well as the wiring works properly. This is the code I use:
static void Main()
{
Application.Run(new Form1());
}
//*** in Form1 class***//
public System.IO.Ports.SerialPort _serialPort;
public Form1()
{
InitializeComponent();
openPort();
}
public void openPort()
{
_serialPort = new System.IO.Ports.SerialPort(); _serialPort.PortName = "COM1";
_serialPort.BaudRate = 9600;
_serialPort.Parity = (Parity)0;
_serialPort.DataBits = 8;
_serialPort.StopBits = (StopBits)1;
_serialPort.Handshake = (Handshake)0;
// Set the read/write timeouts
_serialPort.ReadTimeout = 500;
_serialPort.WriteTimeout = 500;
_serialPort.Open();
}
If I try to write to the port there is a null reference exception. Has it possibly anything to do with threading, should I start an own thread for initiating the port?
Andrew Arnott
Can you please explain the action you suggest in this
thread, does it mean all resources are correctly disposed if the application is premature shut down?
This is the code snippet I am talking about;
using (SerialPort sp = new SerialPort("COM4"))
{
sp.Open();
byte[] someData = new byte[1];
someData = ASCII.GetBytes("hi");
sp.Write(someData, 0, someData.Length);
}Where should I put this snippet? In the same place where I normally have the sp.open() command?
I believe so since it is in a "using" statement which means that the class instance will be disposed off correctly after finishing using that statement/block of code. It is also best practice to do this in general, with such things like SQL Connections, StreamReader/Writers and so on
These are the exceptions I get, even when I have the "using" snippet.at System.IO.Ports.SerialStream.WinIOError()
at System.IO.Ports.SerialStream..ctor()
at System.IO.Ports.SerialPort.Open()
at DevApp.Form1.openPort()
at DevApp.Form1..ctor()
at DevApp.Program.Main()
Where can I find information about this System.IO.Ports.SerialStream class?
I have been able to run similar programs on my PDA earlier, but I suspect the serial port used was in some way already created by the PC while testing. This is why I am interested in the initialization and disposal of serial port objects.
looks like your hitting the same problem I have right now
Even if this problem has no general answers, because of the different PDA:s we are using, I am surprised by the unstability in the com port handling. As I said I have communicated through COM1 earlier on this device, now I can't even open the port.
I do in some way think it has to do with the resource handling in my PDA. Maybe the com port stays open and occupied when I exit the debugger prematurely, and hence is not available when I run the debugger next time? So can anybody please help with a link, code or tutorial how to write resource safe code that does not stay in the memory if the debugger is stopped?
| I am surprised by the unstability in the com port handling. As I said I have communicated through COM1 earlier on this device, now I can't even open the port. |
|
Unmanaged resources such as serial ports are always fragile like this.
| Maybe the com port stays open and occupied when I exit the debugger prematurely, and hence is not available when I run the debugger next time? So can anybody please help with a link, code or tutorial how to write resource safe code that does not stay in the memory if the debugger is stopped? |
|
When you use the using clause for opening/closing the serial port, even an early debugger termination will normally close the port properly. I believe the same is true for a try/finally block.
If you used to be able to open the port and now you can't, the problem is usually that the port was left open. The only way (that I know of) to fix this is a soft-reset of the device. Then go in there and fix the code to not leave the port open. :)
