Can .Net CF do real time I/O and comm?

Our company is evaluating new technologies for a new product. I am a big fan
of using widely supported, easy to use, off the shelf technology as much as
possible. The application involved uses industrial I/O. I, personally,
would prefer to program in C# with an integrated debugger, but some of my
colleagues insist that the .Net Compact Framework is totally unsuited to the
task, because it is "not real time". If they win, we have to end up
developing in C on some sort of embedded development package, which seems to
me a big step down.

The application involves digital I/O in a machine on a factory floor. The
application will receive a message on the Ethernet port. Within 2
milliseconds, it must set the digital I/O bit, turning off the motor it is
controlling. After that, it is guaranteed that nothing important will happen
for the next 500 milliseconds.

It seemed to me that the .NET compact framework is well suited to the task
because the only non real time aspect is garbage collection. We can run the
task, get the message, set the bit, and force a garbage collection after we
are done, during the 500 millisecond idle time. That way, we will never end
up with a GC that interrupts anything important.

My colleagues are not sold on this idea. They have read that it is "not
real time", and that is that.

Can anyone offer supporting examples of using the .NET Compact (or even
Micro) framework on such a task?

Paul
Thu Mar 13 12:59:07 CDT 2008

There are things that you can do to improve the real-time performance of
.NET CF. Search back in the archives for posts from Chris Tacke about doing
this. However, as you noted, any time a garbage collection occurs, all
managed threads are going to be suspended, and you don't know for how long.

Since the process that you describe is very simple in C, I don't see the
advantage of writing this program in managed code. What are you getting out
of using .NET CF (this standard framework that is widely supported, etc.,
that you're talking about), as opposed to Win32 (which is even more widely
supported). It's not like there's some non-off-the-shelf aspect of writing
this code is C; the things that you lose are the simplicity of building
complex UIs and data-driven applications. If all you're doing is responding
to a network message and driving some DIO, you're not getting anything out
of the .NET CF anyway (and you'd have to do the DIO wrappers, unless your
device vendor has a managed code wrapper for them already).

Paul T.

"David" <David@blackdeck.com> wrote in message
news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
> Our company is evaluating new technologies for a new product. I am a big
> fan
> of using widely supported, easy to use, off the shelf technology as much
> as
> possible. The application involved uses industrial I/O. I, personally,
> would prefer to program in C# with an integrated debugger, but some of my
> colleagues insist that the .Net Compact Framework is totally unsuited to
> the
> task, because it is "not real time". If they win, we have to end up
> developing in C on some sort of embedded development package, which seems
> to
> me a big step down.
>
> The application involves digital I/O in a machine on a factory floor. The
> application will receive a message on the Ethernet port. Within 2
> milliseconds, it must set the digital I/O bit, turning off the motor it is
> controlling. After that, it is guaranteed that nothing important will
> happen
> for the next 500 milliseconds.
>
> It seemed to me that the .NET compact framework is well suited to the task
> because the only non real time aspect is garbage collection. We can run
> the
> task, get the message, set the bit, and force a garbage collection after
> we
> are done, during the 500 millisecond idle time. That way, we will never
> end
> up with a GC that interrupts anything important.
>
> My colleagues are not sold on this idea. They have read that it is "not
> real time", and that is that.
>
> Can anyone offer supporting examples of using the .NET Compact (or even
> Micro) framework on such a task?

Chris
Thu Mar 13 13:27:03 CDT 2008

I've used the CF in several controls type applications to some degree or
another, but for the requirements you're stating that the CF is absolutely
incapable of meeting your needs. Could the system be made to work *most* of
the time and so that getting it to fail in real-world testing is near
impossible? Sure - I can already envision the architecture that woudl get
you there. Getting to the point where you're certain the GC will never
interfere is likely doable in the basic scenario you outlined, but the
problem will come with the inevitable extension of the application to do
more, and the eventual code that will make an allocation of some sort while
your real-time thread is blocked waiting for that interrupt, the GC will
kick in, suspend your IST and you'll service it many, many milliseconds
late.

The CF buys you nothing with what you've stated so far. You can use native
code and do all the stepping and debugging you need from Visual Studio too,
so assuming that the CF is the only way to get that is incorrect.

Now if you need to add a UI that display stuff about your real-time system
or does data logging or something like that, then yes, using the CF makes
sense (and then you'll still run your IST in a native DLL that you call).

Food for thought:
http://community.opennetcf.com/articles/cf/archive/2008/01/31/performance-implications-of-crossing-the-p-invoke-boundary.aspx
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"David" <David@blackdeck.com> wrote in message
news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
> Our company is evaluating new technologies for a new product. I am a big
> fan
> of using widely supported, easy to use, off the shelf technology as much
> as
> possible. The application involved uses industrial I/O. I, personally,
> would prefer to program in C# with an integrated debugger, but some of my
> colleagues insist that the .Net Compact Framework is totally unsuited to
> the
> task, because it is "not real time". If they win, we have to end up
> developing in C on some sort of embedded development package, which seems
> to
> me a big step down.
>
> The application involves digital I/O in a machine on a factory floor. The
> application will receive a message on the Ethernet port. Within 2
> milliseconds, it must set the digital I/O bit, turning off the motor it is
> controlling. After that, it is guaranteed that nothing important will
> happen
> for the next 500 milliseconds.
>
> It seemed to me that the .NET compact framework is well suited to the task
> because the only non real time aspect is garbage collection. We can run
> the
> task, get the message, set the bit, and force a garbage collection after
> we
> are done, during the 500 millisecond idle time. That way, we will never
> end
> up with a GC that interrupts anything important.
>
> My colleagues are not sold on this idea. They have read that it is "not
> real time", and that is that.
>
> Can anyone offer supporting examples of using the .NET Compact (or even
> Micro) framework on such a task?

David
Thu Mar 13 14:56:00 CDT 2008

Thanks for the answer.

The application actually does quite a bit more than I described, which is
why I would prefer C#, but you have a good point. Win32 in Windows CE could
be used. The biggest thing I want to accomplish is to use Visual Studio for
code development, and ever since C# came out, it's all I've used to program.

The full application does a whole bunch of stuff with that message. It has
to run a process, and also provide data about the process. The process
itself takes about 100 milliseconds and can occur about once every two
seconds. Basically, there's a "prepare to process" message. At that point,
it suspends other activity, and waits for a "start process" command. When
the "start process" comes in, it sets some digital I/O and waits for a "stop
process". When the "stop process" comes in, it has 2 milliseconds to set the
digital I/O that will stop the system, and 500 milliseconds to send back a
response. During other times, it responds to status requests, but there is
no real time requirement, and it can choose not to answer when something
important is happening.

That 2 millisecond response time is the only true real time requirement in
the whole system, and we can control everything that might interrupt it,
except garbage collection. I thought that by forcing a garbage collection at
the end of every cycle, we could guarantee that the garbage collection never
interrupted a cycle. Meanwhile, all of the other information processing
requests would be a lot easier to write in C# than in other languages. Even
more importantly, I've found that ever since I switched to the .NET framework
and CF, my code just works a lot better. It is much, much, more likely to
work the first time, and I've found a lot fewer bugs in deployed
applications, so I really would like to use it.

On the other hand, it is true that we could get by in C for Win32 and have
no real issues. I'm just too lazy to go back to learning C if I don't have
to.

"Paul G. Tobey [eMVP]" wrote:

> There are things that you can do to improve the real-time performance of
> ..NET CF. Search back in the archives for posts from Chris Tacke about doing
> this. However, as you noted, any time a garbage collection occurs, all
> managed threads are going to be suspended, and you don't know for how long.
>
> Since the process that you describe is very simple in C, I don't see the
> advantage of writing this program in managed code. What are you getting out
> of using .NET CF (this standard framework that is widely supported, etc.,
> that you're talking about), as opposed to Win32 (which is even more widely
> supported). It's not like there's some non-off-the-shelf aspect of writing
> this code is C; the things that you lose are the simplicity of building
> complex UIs and data-driven applications. If all you're doing is responding
> to a network message and driving some DIO, you're not getting anything out
> of the .NET CF anyway (and you'd have to do the DIO wrappers, unless your
> device vendor has a managed code wrapper for them already).
>
> Paul T.
>
> "David" <David@blackdeck.com> wrote in message
> news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
> > Our company is evaluating new technologies for a new product. I am a big
> > fan
> > of using widely supported, easy to use, off the shelf technology as much
> > as
> > possible. The application involved uses industrial I/O. I, personally,
> > would prefer to program in C# with an integrated debugger, but some of my
> > colleagues insist that the .Net Compact Framework is totally unsuited to
> > the
> > task, because it is "not real time". If they win, we have to end up
> > developing in C on some sort of embedded development package, which seems
> > to
> > me a big step down.
> >
> > The application involves digital I/O in a machine on a factory floor. The
> > application will receive a message on the Ethernet port. Within 2
> > milliseconds, it must set the digital I/O bit, turning off the motor it is
> > controlling. After that, it is guaranteed that nothing important will
> > happen
> > for the next 500 milliseconds.
> >
> > It seemed to me that the .NET compact framework is well suited to the task
> > because the only non real time aspect is garbage collection. We can run
> > the
> > task, get the message, set the bit, and force a garbage collection after
> > we
> > are done, during the 500 millisecond idle time. That way, we will never
> > end
> > up with a GC that interrupts anything important.
> >
> > My colleagues are not sold on this idea. They have read that it is "not
> > real time", and that is that.
> >
> > Can anyone offer supporting examples of using the .NET Compact (or even
> > Micro) framework on such a task?
>
>
>

Chris
Thu Mar 13 15:09:16 CDT 2008

As I suspected, the system is more complex, meaning getting real-time
behavior would be that much more difficult. Your best bet here is a hybrid.
Use the CF for all of the non-real-time stuff and put the real-tiem IST out
in a native DLL that you initialize through a P/Invoke early on. You can
then use a native named event set in the IST to trigger a managed event in
your CF code and carry on as nornal from that point.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"David" <David@blackdeck.com> wrote in message
news:EAD1A000-0879-4156-B918-10178005CB59@microsoft.com...
> Thanks for the answer.
>
> The application actually does quite a bit more than I described, which is
> why I would prefer C#, but you have a good point. Win32 in Windows CE
> could
> be used. The biggest thing I want to accomplish is to use Visual Studio
> for
> code development, and ever since C# came out, it's all I've used to
> program.
>
> The full application does a whole bunch of stuff with that message. It has
> to run a process, and also provide data about the process. The process
> itself takes about 100 milliseconds and can occur about once every two
> seconds. Basically, there's a "prepare to process" message. At that
> point,
> it suspends other activity, and waits for a "start process" command. When
> the "start process" comes in, it sets some digital I/O and waits for a
> "stop
> process". When the "stop process" comes in, it has 2 milliseconds to set
> the
> digital I/O that will stop the system, and 500 milliseconds to send back a
> response. During other times, it responds to status requests, but there
> is
> no real time requirement, and it can choose not to answer when something
> important is happening.
>
> That 2 millisecond response time is the only true real time requirement in
> the whole system, and we can control everything that might interrupt it,
> except garbage collection. I thought that by forcing a garbage collection
> at
> the end of every cycle, we could guarantee that the garbage collection
> never
> interrupted a cycle. Meanwhile, all of the other information processing
> requests would be a lot easier to write in C# than in other languages.
> Even
> more importantly, I've found that ever since I switched to the .NET
> framework
> and CF, my code just works a lot better. It is much, much, more likely to
> work the first time, and I've found a lot fewer bugs in deployed
> applications, so I really would like to use it.
>
> On the other hand, it is true that we could get by in C for Win32 and have
> no real issues. I'm just too lazy to go back to learning C if I don't
> have
> to.
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> There are things that you can do to improve the real-time performance of
>> ..NET CF. Search back in the archives for posts from Chris Tacke about
>> doing
>> this. However, as you noted, any time a garbage collection occurs, all
>> managed threads are going to be suspended, and you don't know for how
>> long.
>>
>> Since the process that you describe is very simple in C, I don't see the
>> advantage of writing this program in managed code. What are you getting
>> out
>> of using .NET CF (this standard framework that is widely supported, etc.,
>> that you're talking about), as opposed to Win32 (which is even more
>> widely
>> supported). It's not like there's some non-off-the-shelf aspect of
>> writing
>> this code is C; the things that you lose are the simplicity of building
>> complex UIs and data-driven applications. If all you're doing is
>> responding
>> to a network message and driving some DIO, you're not getting anything
>> out
>> of the .NET CF anyway (and you'd have to do the DIO wrappers, unless your
>> device vendor has a managed code wrapper for them already).
>>
>> Paul T.
>>
>> "David" <David@blackdeck.com> wrote in message
>> news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
>> > Our company is evaluating new technologies for a new product. I am a
>> > big
>> > fan
>> > of using widely supported, easy to use, off the shelf technology as
>> > much
>> > as
>> > possible. The application involved uses industrial I/O. I,
>> > personally,
>> > would prefer to program in C# with an integrated debugger, but some of
>> > my
>> > colleagues insist that the .Net Compact Framework is totally unsuited
>> > to
>> > the
>> > task, because it is "not real time". If they win, we have to end up
>> > developing in C on some sort of embedded development package, which
>> > seems
>> > to
>> > me a big step down.
>> >
>> > The application involves digital I/O in a machine on a factory floor.
>> > The
>> > application will receive a message on the Ethernet port. Within 2
>> > milliseconds, it must set the digital I/O bit, turning off the motor it
>> > is
>> > controlling. After that, it is guaranteed that nothing important will
>> > happen
>> > for the next 500 milliseconds.
>> >
>> > It seemed to me that the .NET compact framework is well suited to the
>> > task
>> > because the only non real time aspect is garbage collection. We can
>> > run
>> > the
>> > task, get the message, set the bit, and force a garbage collection
>> > after
>> > we
>> > are done, during the 500 millisecond idle time. That way, we will
>> > never
>> > end
>> > up with a GC that interrupts anything important.
>> >
>> > My colleagues are not sold on this idea. They have read that it is
>> > "not
>> > real time", and that is that.
>> >
>> > Can anyone offer supporting examples of using the .NET Compact (or even
>> > Micro) framework on such a task?
>>
>>
>>

Paul
Thu Mar 13 15:53:12 CDT 2008

I use Visual Studio for native code development with CE5 and later and 95%
of what I do is native code.

I don't think that it's actually any easier to write message-processing in
C# than C or C++. You might be more used to it, but it's not like there's
something built into C# that parses your messages for you.

I think that, for real-time, you have to (return to C or C++). As Chris
indicated, you can create your real-time, native code components as a DLL
and P/Invoke to that DLL's interface from C#. You need native threads,
though, to accomplish what you describe.

Paul T.

"David" <David@blackdeck.com> wrote in message
news:EAD1A000-0879-4156-B918-10178005CB59@microsoft.com...
> Thanks for the answer.
>
> The application actually does quite a bit more than I described, which is
> why I would prefer C#, but you have a good point. Win32 in Windows CE
> could
> be used. The biggest thing I want to accomplish is to use Visual Studio
> for
> code development, and ever since C# came out, it's all I've used to
> program.
>
> The full application does a whole bunch of stuff with that message. It has
> to run a process, and also provide data about the process. The process
> itself takes about 100 milliseconds and can occur about once every two
> seconds. Basically, there's a "prepare to process" message. At that
> point,
> it suspends other activity, and waits for a "start process" command. When
> the "start process" comes in, it sets some digital I/O and waits for a
> "stop
> process". When the "stop process" comes in, it has 2 milliseconds to set
> the
> digital I/O that will stop the system, and 500 milliseconds to send back a
> response. During other times, it responds to status requests, but there
> is
> no real time requirement, and it can choose not to answer when something
> important is happening.
>
> That 2 millisecond response time is the only true real time requirement in
> the whole system, and we can control everything that might interrupt it,
> except garbage collection. I thought that by forcing a garbage collection
> at
> the end of every cycle, we could guarantee that the garbage collection
> never
> interrupted a cycle. Meanwhile, all of the other information processing
> requests would be a lot easier to write in C# than in other languages.
> Even
> more importantly, I've found that ever since I switched to the .NET
> framework
> and CF, my code just works a lot better. It is much, much, more likely to
> work the first time, and I've found a lot fewer bugs in deployed
> applications, so I really would like to use it.
>
> On the other hand, it is true that we could get by in C for Win32 and have
> no real issues. I'm just too lazy to go back to learning C if I don't
> have
> to.
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> There are things that you can do to improve the real-time performance of
>> ..NET CF. Search back in the archives for posts from Chris Tacke about
>> doing
>> this. However, as you noted, any time a garbage collection occurs, all
>> managed threads are going to be suspended, and you don't know for how
>> long.
>>
>> Since the process that you describe is very simple in C, I don't see the
>> advantage of writing this program in managed code. What are you getting
>> out
>> of using .NET CF (this standard framework that is widely supported, etc.,
>> that you're talking about), as opposed to Win32 (which is even more
>> widely
>> supported). It's not like there's some non-off-the-shelf aspect of
>> writing
>> this code is C; the things that you lose are the simplicity of building
>> complex UIs and data-driven applications. If all you're doing is
>> responding
>> to a network message and driving some DIO, you're not getting anything
>> out
>> of the .NET CF anyway (and you'd have to do the DIO wrappers, unless your
>> device vendor has a managed code wrapper for them already).
>>
>> Paul T.
>>
>> "David" <David@blackdeck.com> wrote in message
>> news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
>> > Our company is evaluating new technologies for a new product. I am a
>> > big
>> > fan
>> > of using widely supported, easy to use, off the shelf technology as
>> > much
>> > as
>> > possible. The application involved uses industrial I/O. I,
>> > personally,
>> > would prefer to program in C# with an integrated debugger, but some of
>> > my
>> > colleagues insist that the .Net Compact Framework is totally unsuited
>> > to
>> > the
>> > task, because it is "not real time". If they win, we have to end up
>> > developing in C on some sort of embedded development package, which
>> > seems
>> > to
>> > me a big step down.
>> >
>> > The application involves digital I/O in a machine on a factory floor.
>> > The
>> > application will receive a message on the Ethernet port. Within 2
>> > milliseconds, it must set the digital I/O bit, turning off the motor it
>> > is
>> > controlling. After that, it is guaranteed that nothing important will
>> > happen
>> > for the next 500 milliseconds.
>> >
>> > It seemed to me that the .NET compact framework is well suited to the
>> > task
>> > because the only non real time aspect is garbage collection. We can
>> > run
>> > the
>> > task, get the message, set the bit, and force a garbage collection
>> > after
>> > we
>> > are done, during the 500 millisecond idle time. That way, we will
>> > never
>> > end
>> > up with a GC that interrupts anything important.
>> >
>> > My colleagues are not sold on this idea. They have read that it is
>> > "not
>> > real time", and that is that.
>> >
>> > Can anyone offer supporting examples of using the .NET Compact (or even
>> > Micro) framework on such a task?
>>
>>
>>

David
Thu Mar 13 16:08:04 CDT 2008

Thanks a lot. That makes a lot of sense. I've gotten into the mindset of
thinking that development environment=.NET framework, but the tools will work
just as well in native code, and we still won't have to go out and buy all
new compilers. I'll just have to dust off the brain cells on how to do
native development.

Thanks a lot.


"Chris Tacke, eMVP" wrote:

> I've used the CF in several controls type applications to some degree or
> another, but for the requirements you're stating that the CF is absolutely
> incapable of meeting your needs. Could the system be made to work *most* of
> the time and so that getting it to fail in real-world testing is near
> impossible? Sure - I can already envision the architecture that woudl get
> you there. Getting to the point where you're certain the GC will never
> interfere is likely doable in the basic scenario you outlined, but the
> problem will come with the inevitable extension of the application to do
> more, and the eventual code that will make an allocation of some sort while
> your real-time thread is blocked waiting for that interrupt, the GC will
> kick in, suspend your IST and you'll service it many, many milliseconds
> late.
>
> The CF buys you nothing with what you've stated so far. You can use native
> code and do all the stepping and debugging you need from Visual Studio too,
> so assuming that the CF is the only way to get that is incorrect.
>
> Now if you need to add a UI that display stuff about your real-time system
> or does data logging or something like that, then yes, using the CF makes
> sense (and then you'll still run your IST in a native DLL that you call).
>
> Food for thought:
> http://community.opennetcf.com/articles/cf/archive/2008/01/31/performance-implications-of-crossing-the-p-invoke-boundary.aspx
> http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
> "David" <David@blackdeck.com> wrote in message
> news:36AAB259-E0A0-4D4E-A748-8DB8E00885A0@microsoft.com...
> > Our company is evaluating new technologies for a new product. I am a big
> > fan
> > of using widely supported, easy to use, off the shelf technology as much
> > as
> > possible. The application involved uses industrial I/O. I, personally,
> > would prefer to program in C# with an integrated debugger, but some of my
> > colleagues insist that the .Net Compact Framework is totally unsuited to
> > the
> > task, because it is "not real time". If they win, we have to end up
> > developing in C on some sort of embedded development package, which seems
> > to
> > me a big step down.
> >
> > The application involves digital I/O in a machine on a factory floor. The
> > application will receive a message on the Ethernet port. Within 2
> > milliseconds, it must set the digital I/O bit, turning off the motor it is
> > controlling. After that, it is guaranteed that nothing important will
> > happen
> > for the next 500 milliseconds.
> >
> > It seemed to me that the .NET compact framework is well suited to the task
> > because the only non real time aspect is garbage collection. We can run
> > the
> > task, get the message, set the bit, and force a garbage collection after
> > we
> > are done, during the 500 millisecond idle time. That way, we will never
> > end
> > up with a GC that interrupts anything important.
> >
> > My colleagues are not sold on this idea. They have read that it is "not
> > real time", and that is that.
> >
> > Can anyone offer supporting examples of using the .NET Compact (or even
> > Micro) framework on such a task?
>
>
>