Re: All RTOS (linux Based ) Other than RT-Linux

Matt Giwer wrote:

Thats not generally enough for many peoples definitions, which is that
the time to respond to an (external) interrupt is fast, un blockable,
and well defined.

I realize there are many definitions. However what you suggest is what
"nice" is for. Having a real time OS and tailoring it are two different
matters.

Actually, "nice" is for batch jobs vs interactive ones. Has nothing to do
with interrupts.

However, there are real-time extensions to Unix/Linux which allow fixed
priorities, no swapping, task activation/resumption on specified interrupts,
etc.. While not enough for "hard" real time with rapid responses, the
extensions are more than adequate for the average process control or SCADA
system. One of the projects I was involved in ran an aluminum smelter SCADA
system. It's been installed in several smelters around the world. Works
fine.

Use of the extensions does take a little getting used to. For example, to run
a task every 5 milliseconds one does not exit and request reactivation in the
said 5 milliseconds. Instead, request the time when activated and at the end
of each iteration request reactivation or resumption in 5 milliseconds minus
however long the current iteration took.

--
It's turtles, all the way down.
.

Relevant Pages

  • Re: Latency traces I cannot interpret (sa1100, 2.6.15-rc7-rt1)
    ... >> Interrupts seem to be blocked for milliseconds, ... there are console-related function names ... > interrupts, or there's a bug in the latency tracer. ...
    (Linux-Kernel)
  • Re: windows = realtime?
    ... but 20 milliseconds! ... Mike Powers wrote: ... > The physical interrupts are prioritized. ... > interrupts at the same time, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: windows = realtime?
    ... but 20 milliseconds! ... Mike Powers wrote: ... > The physical interrupts are prioritized. ... > interrupts at the same time, ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: windows = realtime?
    ... but 20 milliseconds! ... Mike Powers wrote: ... > The physical interrupts are prioritized. ... > interrupts at the same time, ...
    (microsoft.public.development.device.drivers)