467,174 Members | 1,335 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,174 developers. It's quick & easy.

Serial port in .NET

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.

Nov 9 '07 #1
  • viewed: 4440
Share:
4 Replies
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
Nov 9 '07 #2
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" <maxime.montser...@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
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.


Nov 10 '07 #3
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

Nov 10 '07 #4
On 10 nov, 21:02, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.comwrote:
On 2007-11-10 04:13:50 -0800, max_mont <maxime.montser...@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
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

Nov 11 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by ^CeFoS^ | last post: by
2 posts views Thread by willie@macleod-group.com | last post: by
3 posts views Thread by collinm | last post: by
13 posts views Thread by Al the programmer | last post: by
13 posts views Thread by Rob | last post: by
4 posts views Thread by rowan@sylvester-bradley.org | last post: by
3 posts views Thread by naveen.sabapathy@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.