Interrupt handling mechanism and latency ???
Maciek
industrial control applications.
Please, don't answer me "microframework is not-real-time" because the term
doesn't seem to be very precise and it means different things to different
developers!
(I'm trying to figure out what microframework IS)
Below is the summary of what I (probably) know...
and what I suppose is wright.
PLEASE CORRECT ME IF I'M WRONG (big thanks for any comments)!!!
1. I understand that the thread switching and interrupt flags checking is
done every 20ms. Thus, without GC and events and with one interrupt only -
this interrupt should be processed after 20ms in the worst case (no matter
how many threads are running)!
In case of running GC or blocking by other being processed interrupts - it
may take indefinitely longer...
2. If there are no running threads (no user threads, no GC...) - interrupts
are processed immediately; depending on hardware - latency about 1ms
(I suppose:)
3. Internal event handling is done using similar mechanisms to the interrupt
handling. Actually I suppose that hardware interrupts result in raising
standard events - this way standard events generated in code may "look" the
same as hardware interrupts and may postpone hardware interrupts handling.
(This make hardware interrupts handling less predictable).
(Question: HOW THOSE NEW THREADS - for interrupt/event handlers - ARE
SCHEDULED? Is there any way of controlling this scheduling?)
AM I CORRECT ?
Simply put: I can tolerate 20-40ms latency, but I can't tolerate 50ms
(damaged device) - is there any way of programming to avoid such big
latencies ?
(Programming like:
- periodically using GC manually
- controlling priorities etc.)
I can always design with additional microcontroller for RT part, but I
should know the limitations.
Many Thanks for comments
Maciek
ps. maybe there is some good source of information somwhere ???
Lorenzo Tessiore
here are the answers:
1. CORRECT
2. CORRECT
3. CORRENT and the threads that dispatch the "interrupt" events ( as you
say, interrupts are dispatched teh same way as other HW events are
dispacthed, e.g. a DataAvailable event from the serial port) are system
threads (there is one for the timers and oen for "interrupts", look at the
code in method 'CLR_HW_Hardware::SpawnDispatcher' in the
CLR\Core\Interrupthandler directory of the PK). The thread is started witha
very high priority and so:
1) if you have no other threads to run
2) if there is no GC
you can be reasonably sure that the system will handle a 40ms latency.
you can control the GC by runnign it periodically (call Debug.GC(true)
periodically)and pre-allocate the resources you need on teh interrupt handler
processing.
you can be reasonably sure that no other threads are running by not having
polling loops, periodic timers, etc... and instead using heavily an event
driven programmign style.
Cheers
Lorenzo
Maciek
When I ask this question I usually obtain the answer
"not real-time" or "not real-time because of GC".
But I actually suppose that this mechanism of "mapping interrupts into
events" is the true reason of non-real-time behavior (and is more difficult to
control).
I understand Your last comment, but now I'm pretty sure I will divide the
whole
application into RT and non-RT parts. It's extremely common situation that
the RT
part of application is very very simple! The hardest coding is done mostly
on non-RT part.
This suggests solution also.
Again many many thanks for Your comment.
Best regards
Maciek
GHI Team
All said is true but you still want to be careful of what you are
controlling and why 40ms or less is important. For example, some rare SD
cards may take long time to mount and so you will not see 40ms at all while
mounting a media!
You can almost guarantee latency only if you design your application with
everything Lorenzo listed in mind.
Maybe instead of asking what is the latency, give a hint of your application
then we can tell you if this will work or not. For example, one of our
customer has Embedded Master connected to a vending machine. They require
that they run a motor for a very specific time in order to feed out one of
the items. Note how timing is required for only short time. This is no
problem for NETMF because they are not doing anything while running the
motor and they enable the GC right before they start the timing, so the GC
will not kick in randomly. So, for this example, NETMF is still not real
time but we did guarantee the time for this specific task.
GHI Team
www.ghielectronics.com
"Maciek" <Mac...@discussions.microsoft.com> wrote in message
news:82AC424E-03DF-4CEE...@microsoft.com...
Steve Maillet
> I understand Your last comment, but now I'm pretty sure I will divide the
> whole
> application into RT and non-RT parts. It's extremely common situation that
> the RT
> part of application is very very simple! The hardest coding is done mostly
> on non-RT part.
> This suggests solution also.
Yes!
That's how to do things. Even if .NET MF was officially a RT-Kernel it would
still be the way to go. Isolating the parts that require RT to the smallest
possible scope helps to reduce complexity and eliminate errors.
Steve Maillet
news:82AC424E-03DF-4CEE...@microsoft.com...
>
> When I ask this question I usually obtain the answer
> "not real-time" or "not real-time because of GC".
and controlled case versus being possible in the general. It is not possible
to say in general that real-time constraints can be met with .NET MF in it's
current implementation. (Note: a future implementation could change that!)
However in some specific cases it can be, however it's very difficult to
guarantee you've covered all possible edge cases in the NET MF that could
impact scheduling of IL code in response to an interrupt.
> But I actually suppose that this mechanism of "mapping interrupts into
> events" is the true reason of non-real-time behavior (and is more
> difficult to
> control).
Not really, no. CE and most other RTOSs do that too. Although the
implementation details are radically different. The 20ms context switch
doesn't mean that a new thread starts every 20ms as the CLR will also run
native code callbacks at that time as well, and those can take an
indeterminate amount of time or disable interrupts etc... Thus the .NET MF
is not classified as a RT system. In some cases you can make something work
if you carefully analyze all of the factors and parts.