Re: Realtime OS needed
On Tue, Apr 08, 2003 at 11:57:09AM +0200, martin f krafft wrote:
> Folks,
>
> We are building a robot, and have been advised to use QNX
> (www.qnx.com) for that. QNX is a real-time OS that claims POSIX
> compliance. All nice and well, but I want APT and my familiar Linux
> environment.
FWIW, I have never used QNX, but I have read quite a bit about how it is
implemented, and I would go as far as saying that QNX is the only OS worth
paying for.
It is a true micro-kernel, and is great for multi-processor stuff. You can
do things like run the TCP stack on a different processor from the processor
using it for communications.
Because it is posix compilant, all the Linux utilities you are familiar with
are usually just a "make install" away.
> I know that there are realtime patches for Linux floating around. So
> I am wondering if any of you have had experience with any of those
> patches. Are they reliable and usable, and do they allow my
> controllers to run in real-time while I can still maintain the box
> with my Debian knowledge?
I've not used them, but I have read a bit about them. They range from the
extreme "run linux as a process on top of a RT OS", to "Hmm, lets see
what we can do to reduce interrupt latency". The hardest part of using these
would be figuring out how. By the time you got past the "figure out how"
phase, you would probably be committed to the point of making the problem
fit the capabilities instead of the other way around.
> Lastly: does anyone have a good document covering realtime, what
> it's needs are, and what it does? I know that realtime means that
> processes don't get put in a queue but run immediately. How that
> works with a multi-tasking OS is a bit foggy to me. Moreover, what's
> the difference between a process on a realtime OS, and one with
> nice -20?
This is probably one of those "if you have to ask, you probably don't need
it" questions.
"real time" has become a bit of a buzz-word bandied around by marketing
types taking advantage of it's vaugeness.
I "grew up" in an environment where OS schedulers were an unknown you
couldn't trust (or just unknown), so you wrote your own. We would be running
digital filters on 1ms sample intervals, and you would pad any branches with
no-ops to ensure deterministic execution times. If you didn't sample at
exactly 1ms intervals, the variation _could_ trigger frequencies in the
filters that would throw things out wildly <insert old-geezer whistful
eye-glaze>.
(hard) real time is all about deterministic behaviour. It doesn't matter if
it takes 500us to service an interrupt, as long as it _always_ takes 500us
to service the interrupt. You can then take this into account in your
design. If you want a task to run every 2ms, you want it to be every 2ms +-
1us, not every 2ms +- 1ms.
With modern RT OS's, the bit about "don't queue, run immediately" is
probably wrong. They would probably still queue, they would just have better
prioritising (and pre-empting of lower priority tasks) so that you can
gaurentee certain responce times to tasks that need it. Even the best RT OS
can be overloaded if you try to run more than it can handle. Ironically, non
RT OS's are often more efficient with the CPU because they prioritise "more
work done" over "work at the right time".
Thanks for the oppertunity to ramble... sorry I couldn't offer anything useful.
--
----------------------------------------------------------------
Donovan Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------
Reply to: