Topic tags:[Arch][Wiring][Doc][HW][PM]
_______________________________________________
>James raises a good point:
>
>> I think it is the real-time nature of Embedded programming that puts
>> people in a bit of a spin.
>
>I've been thinking about this. Creation of a container implementation that
can
>support real-time (in the strict, embedded sense of the word) is a very
difficult
>task.
>>Scheduling of multiple threads is the only place that predictable
latencies
>>get shot down. Realtime only requires predictable latencies to design a
>>system that provides the required functionality. RTSJ is primarily about
>>resolving this issue. GC is another problem that RTSJ addresses by making
it
>>possible to designate threads as non-garbage generating. Thus, the
scheduler
>>will still allow them to meet their schedules because the GC process won't
>>need to lock them out of the CPU...
>>So, if you design with RTSJ in mind, you should have no problems putting
>>embedlets into an RTSJ compatible VM...
-----
gr...@cy... (Cyte Technologies Inc)
That was my thought as well. I have been sucessful integrating RT events
such as the AJile GPIO interrupts within an Embedlet-like process component.
A high priority thread reads an ADC into and int variable, then signals a
lower priority thread that is waiting. This second thread is less sensitive
to GC interruption so does not have to be as tidy.
One way to address this would be to have Embedlets designated as
thread-aware or unaware. The guidelines for thread aware Embedlets would be
set out based on RT requirements. It seems that that the container would not
have to be concerned with RT threading. Am I right??
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer
|
