Mon, 11 Oct 1999 Sy Wong wrote:
> The RTlinux apparently fits my definition of time-shared use of a
> processor among more than one (major) tasks and not fit my image of an
> embedded systems.
An "embeded system" can be just about anything... Personally, I'd say a system
is embeded when it's physically integrated with the equipment it's supposed to
control, and tailored to the task to such an extent that it's not really usable
as a general purpose desktop PC, or whatever the system in its standard form
is intended for.
Very flexible indeed... *hehe* Is there actually an official definition that
makes sense? (Hmm... BTW, I'm supposed to be educated in embeded systems
design. All I remember is lots of examples and an even more vague definition.)
Oh, well! In real life, it's about getting the right hardware and software for
the job. As ucLinux, Linux and RTLinux covers a huge range of environments
(and will cover an even wider range of hardware over time), still comes at
a *very* reasonable price, and is Open Source :-), I'm pretty confident it'll
cover most of my current and future OS needs.
> My impression is that the program memory is
> permanently residing inside the processor with statically pre-allocated
> ram space addressed directly. The address allocation are done at code
> generation time during development.
Memory allocation can be done at init time, and even at run time, although
*not* from real time context, as you might be preempting the kernel.
However, as mentioned a few times around here, it's of course possible to set
up a custom memory manager with a preallocated heap. Add a Linux bottom half to
add or remove pages to/from your heap if you like - just keep in mind that
you'll still get "local OOM" if the local heap is exhausted before the bottom
half manages to grab more pages. I bet there are a few various implementations
on this concept... (I have two; C++ class with non-fragmenting alloc/free using
a power-of-2 buffer size heap, and one that's meant for the event system of the
Multimedia Communication System we're designing around the linux-audio-dev
list. The latter uses only inline code except when it needs a new heap buffer,
and uses a form of garbage collection instead of per-block deallocation.)
> Would you need RTLinux if each task
> is assigned to a separate processor where scheduling is implied by system
> wiring?
Not sure what you mean by "processor" in this case... I usually mean CPU if I
say "processor", which means a single chip, or perhaps a core chip and a few
external components in the same package.
If that's what you mean; yes that could work, provided each CPU runs *only*
one task, and not even interrupt handlers. Or, if the "task" is actually the
handler for the only IRQ that's enabled. Other than that, you need to make sure
that no interrupt handler (driver or anything like that) prevents your task
from meeting deadlines.
The DOS hack; set up your own handlers for all IRQs, reenable IRQs ASAP after
entrance in all handlers, and handle priority in software, so that *you* are
in charge of what runs when.
> DOS also fits the "ANY sytem" definition, ignoring my possibly
> incorrect terminologies.
If you're referring to "ANY system that has more than one thread"; no, DOS has
only one thread.
However, if we regard interrups as threads, the interrupt control hardware and
the few intstructions that manipulate it, could be seen as a form of
scheduler. (See above for an explanation of why this isn't really as far
fetched as it may sound...)
> DOS provides the services listed. Is it
> practicable to modify rtlinux to run DOS in lieu of Linux as low level
> task, without and making it a major project?
Well, it should be possible, as you can take control of the interrupts, and
port the RTL API to that layer. However, DOS runs in x86 real mode... (16:16
pointers.) Not fun.
> Could DOS be considered an
> RT task as described in some RTLinux descriptions?
Kind of... Doing it as I described above means that your interrupt layer will
have full control. RT tasks will have highest priority, followed by the old DOS
IRQ handlers, and when all RT tasks sleep, and all DOS interrupts have been
handled, the single "thread" - possibly a DOS application - will run.
Finally: Note that there might be problems with DOS trying to do nasty things
like talking to the interrup controller. As DOS is Closed Source, this can't be
fixed as nicely as with Linux, where the actual kernel code is modified to use
an interrupt emulation layer, giving RTLinux full control without dirty hacks.
//David
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
