Serial port in .NET

[max_mont]

Hi all,
I'm a newbie in .NET technology.
I've already developed Serial communication applications in C++
(WIN32).
And I wanted to migrate to .NET technology.
There is a serial component in framework to read and write on serial
port.
I would like to make asynchronous reception. I saw that we can pass a
delegate to the serial class which is call when some data is readen on
the port.
I suppose that .NET starts a thread to read permanently on the port.

What is the priority of this thread. Is there a way to be sure that
data will be readen before all other events like GUI events ?
How do the delegate work. Is it simply a pointer on a function which
is call or is it an event mechanism ?

Where can I find some details or explanations about that ?

Many thanks in advance for your help.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.
"max_mont" <ma***************@gmail.comwrote in message
news:11********************@o38g2000hse.googlegrou ps.com...

Hi all,
I'm a newbie in .NET technology.
I've already developed Serial communication applications in C++
(WIN32).
And I wanted to migrate to .NET technology.
There is a serial component in framework to read and write on serial
port.
I would like to make asynchronous reception. I saw that we can pass a
delegate to the serial class which is call when some data is readen on
the port.
I suppose that .NET starts a thread to read permanently on the port.

You have to check the docs, but must probably it's not there so you will
have to trust that it will call it :)

What is the priority of this thread.

Again, this is internal implementation, yo should not have to worry about
it. In case you need to know use a tool like reflector and analyze the code.
(not sure if you can legally do it even)

Is there a way to be sure that
data will be readen before all other events like GUI events ?

They are two different sources, why are you worried about it?

How do the delegate work. Is it simply a pointer on a function which
is call or is it an event mechanism ?

A event has a delegate as its type. It's basically a function pointer. You
should read the C# docs about it. MSDN has a good explanation about
events/delegates

[max_mont]

On 9 nov, 21:23, "Ignacio Machin \( .NET/ C# MVP \)" <machin TA
laceupsolutions.comwrote:

Hi,

--
Ignacio Machinhttp://www.laceupsolutions.com
Mobile & warehouse Solutions."max_mont" <[e-mail] in message

news:11********************@o38g2000hse.googlegrou ps.com...

Hi all,
I'm a newbie in .NET technology.
I've already developed Serial communication applications in C++
(WIN32).
And I wanted to migrate to .NET technology.
There is a serial component in framework to read and write on serial
port.
I would like to make asynchronous reception. I saw that we can pass a
delegate to the serial class which is call when some data is readen on
the port.
I suppose that .NET starts a thread to read permanently on the port.

You have to check the docs, but must probably it's not there so you will
have to trust that it will call it :)

What is the priority of this thread.

Again, this is internal implementation, yo should not have to worry about
it. In case you need to know use a tool like reflector and analyze the code.
(not sure if you can legally do it even)

Is there a way to be sure that
data will be readen before all other events like GUI events ?

They are two different sources, why are you worried about it?

How do the delegate work. Is it simply a pointer on a function which
is call or is it an event mechanism ?

A event has a delegate as its type. It's basically a function pointer. You
should read the C# docs about it. MSDN has a good explanation about
events/delegates

Thanks for your response.

In fact, for the moment, I've just develop in C++ where I start a
thread with a high priority to read data on the serial port.
When some data is readen, I call a callback. As I know that my thread
priority is higher than main thread priority, I'm sure that all GUI
actions don't have impact on serial communication.

In .NET technology, I don't know what the serial port priority is.
The serial port sends an event, then a delegate is called, but WHEN ?
and by HOW ?
I'm not sure that for example if a user clicks every seconds on a
button, if the serial data reception won't be blocked.
In fact, in .NET, everything is managed by the framework. So we don't
know what the impact is on the real time aspect.

[Peter Duniho]

On 2007-11-10 04:13:50 -0800, max_mont <ma***************@gmail.comsaid:

Thank you very much for your complete response.

You're welcome.

I think I will use the serial port with Delegate Event and I will see
if there isn't any problem.

Good idea. :)

I'm not worried but I developed in c/c++ language where I knew all
mechanisms.

By that, I assume you mean "I knew all the mechanisms involved in my
implementation". You could have implemented your i/o in C++ using
IOCP, and if you had done so then I believe there would be practically
no difference in the actual implementation between that approach and
using the .NET asynchronous methods.

By migrating to .NET, I would like to know how it's working.

You may want to check out a tool called Reflector if you want the gory
details. I suspect that you'll find that beneath the .NET API, there's
a very conventional and good-performing i/o implementation.

By migrating to .NET, a very higher language than C/C++, we change the
philisophy of development.

Yes, definitely true. But hopefully it's changed for the better. That
is, you can leave behind many of the low-level optimization concerns,
trusting the framework to address those issues for you, and focusing
instead of higher-level algorithm design. There are still plenty of
performance "gotchas" to be found in .NET, but most of the time one
should be able to assume that if there's a significantly superior way
to implement some basic functionality, that's how .NET implements it.

And if you do run into a situation where that's not the case, report it
to Microsoft as a bug. :)

Pete

[max_mont]

On 10 nov, 21:02, Peter Duniho <[e-mail]:

On 2007-11-10 04:13:50 -0800, max_mont <[e-mail]:

Thank you very much for your complete response.

You're welcome.

I think I will use the serial port with Delegate Event and I will see
if there isn't any problem.

Good idea. :)

I'm not worried but I developed in c/c++ language where I knew all
mechanisms.

By that, I assume you mean "I knew all the mechanisms involved in my
implementation". You could have implemented your i/o in C++ using
IOCP, and if you had done so then I believe there would be practically
no difference in the actual implementation between that approach and
using the .NET asynchronous methods.

By migrating to .NET, I would like to know how it's working.

You may want to check out a tool called Reflector if you want the gory
details. I suspect that you'll find that beneath the .NET API, there's
a very conventional and good-performing i/o implementation.

By migrating to .NET, a very higher language than C/C++, we change the
philisophy of development.

Yes, definitely true. But hopefully it's changed for the better. That
is, you can leave behind many of the low-level optimization concerns,
trusting the framework to address those issues for you, and focusing
instead of higher-level algorithm design. There are still plenty of
performance "gotchas" to be found in .NET, but most of the time one
should be able to assume that if there's a significantly superior way
to implement some basic functionality, that's how .NET implements it.

And if you do run into a situation where that's not the case, report it
to Microsoft as a bug. :)

Pete

I surfed on the website of refletor tool and reflector add-in. It
seems to be a powerful tool for .NET developer.
I'm going immediatly to use it.
Thank you very much