Com ports

[}{]

I have an app that reads a character string on com 1, waits for a signal
(any ascii char) on com 2, then outputs the string on com 2.

I seem to have a problem with the timing. It just so happens that the signal
from com2 arrives at the same time as the next string for com1.

Do the com ports run in sepaerate threads by default, or should I be doing
something in code to make this happen.

Thanks.

[christery]

Do the com ports run in sepaerate threads by default, or should I be doing

something in code to make this happen.

I think you should handle the race condition, a mutex solution would
help, there is buffers to use so you wont lose data eaven if waiting
in one receive event until that is finished. but that is a rather bad
way to solve the problem, if a telex isn't read all the way the
process will be hanging there.
UARTS (like 16550) have a small buffer (16 bytes, I think) but issue
an interrupt and will be handeld by the driver, the buffer size is
normally set to larger than the maximum expected packet in your
program language of choice.

//CY

[Peter Duniho]

On Fri, 18 Apr 2008 01:38:20 -0700, }{ <sn****@groups. comwrote:

I have an app that reads a character string on com 1, waits for a signal
(any ascii char) on com 2, then outputs the string on com 2.

I seem to have a problem with the timing. It just so happens that the
signal
from com2 arrives at the same time as the next string for com1.

Do the com ports run in sepaerate threads by default, or should I be
doing
something in code to make this happen.

The "com ports" themselves are handled by the OS. Whether they run in
separate threads or not is immaterial and out of the scope of your
application.

Now, as far as the code in your application that reads the COM ports, .NET
does not introduce new threads to your application's code without your
say-so. If you have written your application as a single-threaded
application, then all of your i/o will be handled in a single-thread.

With most of the i/o classes, there are asynchronous methods that allow
for multi-threaded processing of the i/o. You don't create a thread
explicitly using these methods, but the framework manages special i/o
worker threads that are used whenever some i/o occurs. Your own code
winds up being executed on one or more of these threads, and in that way
the i/o can be dealt with in a multi-threaded way.

I haven't use the SerialPort class (I assume that's what you're using),
and my recollection is that it has a slightly different API that most of
the other i/o classes. So I can't offer specific advice about how best to
approach the multi-threaded issue. However, I can see that the SerialPort
class does have a BaseStream property from which you can get a Stream
instance, and for sure the Stream class provides the asynchronous API I
mentioned above.

That's how I would approach it initially. If for some reason that didn't
work out, then I might look into creating my own threads to deal with the
different ports. But one way or the other, you need to tell .NET via the
code you write that you want a multi-threaded solution, if indeed you do.

Pete

[Gilles Kohl [MVP]]

On Fri, 18 Apr 2008 09:38:20 +0100, "}{" <sn****@groups. comwrote:

>I have an app that reads a character string on com 1, waits for a signal
(any ascii char) on com 2, then outputs the string on com 2.

I seem to have a problem with the timing. It just so happens that the signal
from com2 arrives at the same time as the next string for com1.

Do the com ports run in sepaerate threads by default, or should I be doing
something in code to make this happen.

How are you handling the incoming data, via polling, or by handling
the DataReceived event? I'd recommend the latter. Have a
SerialDataRecei vedEventHandler method for COM1, and another one for
COM2. The first one just buffers received data into a public string,
the second one sends the buffered string to COM2 on reception of the
trigger character, and empties the buffer. (Synchronize on the buffer)

I'm not quite sure how your app should handle characters incoming on
COM2 with no buffered string present from COM1, or indeed multiple
incoming strings on COM1 with not COM2 request in between - you'll
need to decide what to do here. If memory serves, the incoming serial
data received calls are not on the UI thread, not sure though.

Regards,
Gilles.