Read Comport procedure in thread

  • Thread starter Thread starter Leif Eirik Olsen
  • Start date Start date
L

Leif Eirik Olsen

Hi,

I have an CF app that uses a serial (Bluetooth) port. Most of this works ok,
but one problem occures when (if) I for some reason should write to the
wrong port ex. Com6 instead of Com8. Then the app locks up in the write
procedure.

Is this a god idea? :
Create the read/write of comport in an own thread, and in case of read/write
lock up, kill the process. Possible?
If this seems like a good idea, is there any considerations to take in
regards to memory cleanup when killing a process?

I'm using C# and .net 1.1.

Thanks for reading.

Regards,
Leo
 
Ginny Caughey said:
Take a look at
http://www.opennetcf.org/library/OpenNETCF.IO.Ports.BluetoothSerialPort.html.
You can see the source here:
http://vault.netcf.tv/VaultService/VaultWeb/login.aspx (Log in with guest
and guest as user ID and password.)

Thanks Ginny,

I appriciate the links, but I do not see how this answares my question about
reading from a serialport from within a thread, and beeing able to kill that
thread.

Am I missing something obvious here ? :)

regards,
Leo
 
Lief Eirik,

Since I don't know what your code looks like, I can't be more specific. If
you're just working with the Win32 API, one approach to killing a thread is
to call CloseHandle on the serial port and then WaitcommEvent running on
another thread that is blocking will unblock. If you're using the .NET 2.0
SerialPort class, you have to set the Timeout value to zero in one thread,
etc. Those two examples illustrate techniques that work, so if you read
through the source code, you can see exactly what they're doing.
 
Ginny Caughey said:
If you're using the .NET 2.0 SerialPort class, you have to set the Timeout
value to zero in one thread,

Thanks again,

I'm using .net 1.1 (mentioned that in my original post:))

Using the second link you provide and logging on as guest/guest, I do not
see where to download any sourcecode. Mabe I'm stupid (please don't comment
on that:)) Anyway, after login I can browse through different directories,
but can not find any source examples under the Bluetooth folder. Is this
where I should expect to find the examples?

One ex of an folder without any source examples is http://tinyurl.com/89co6

Thank you for your patience.

Regards,
Leo
 
The strategy I usually use for this sort of thing is to close the COM port
from the main thread when it's time for the serial thread to exit.
Presumably, that thread will be sitting inside a read or a write of the port
and, when the port is closed, that read/write will return either having
output only a portion of the requested data or will throw an exception.
Catch the exception, check a global flag, also set by the main thread to
indicate that it's time to exit, and, if set, exit the thread cleanly. Same
basic steps work for socket I/O...

Paul T.
 
Leif Eirik,

Don't feel bad about not immediately seeing how to download the source. Once
you get past the Vault login, click on OpenNETCF. On the next screen click
on SDF. Next screen, click on 1.4. Next click on OpenNETCF. Next IO. Then
Serial. Finally you'll see some links ending in .cs - those are the source
files so click on the ones you're interested in, and finally click on the
Version number to actually download the .cs file.

HTH,
 
Ginny Caughey said:
Leif Eirik,

Don't feel bad about not immediately seeing how to download the source.
Once you get past the Vault login, click on OpenNETCF. On the next screen
click on SDF. Next screen, click on 1.4. Next click on OpenNETCF. Next IO.
Then Serial. Finally you'll see some links ending in .cs - those are the
source files so click on the ones you're interested in, and finally click
on the Version number to actually download the .cs file.

Thanks again, downloading and ready to check the examples now:)

regards,
Leo
 
Paul G. Tobey said:
The strategy I usually use for this sort of thing is to close the COM port
from the main thread when it's time for the serial thread to exit.
Presumably, that thread will be sitting inside a read or a write of the
port and, when the port is closed, that read/write will return either
having output only a portion of the requested data or will throw an
exception. Catch the exception, check a global flag, also set by the main
thread to indicate that it's time to exit, and, if set, exit the thread
cleanly. Same basic steps work for socket I/O...

Thanks alot,

I'm doing a test this moment, looking good so far:)

regards,
Leo
 
Back
Top