Um, isn't that what RTAI does -- run the linux kernel on a
virtualized processor?
Yep, but AFAIK, in the "realtime" part, you need to use what RTAI
offers. You can't install some RTOS there.
As one of my friends used to say: "the only
thing worse than a product based on a microprocessor is one
based on two of them."
So don't use a car ! They include hundreds of them :)
That last qualification is an important one. When I've asked
in the NIOS forums about RTAI or other ways to control latency
on the NIOS/Linux platform, the answer is always "do it in
hardware!". That's fine if you have to toggle pin B whenever
pin A changes, but for things like replying to a message on a
TCP connection such advice is utterly useless.
I feel that replying to a message on a TCP connection is not doable as a
really hard realtime task. There are things like "realtime Ethernet",
but I doubt that it can be used with RTAI and that it can live together
with Linux. You would need to do the complete IP-stack within the
realtime part of the application. Do you in fact have access to code for
such a "realtime Stack" starting from the Ethernet driver and featuring
a complete "zero-copy" UP-stack ? I suppose this code would be done for
a dedicated processor and OS (supposedly not RTAI). I do have access to
such code (propriety by Ubicom). same is especially made for GBit Router
applications.
Not only does NIOS lack RTAI/Xenomi support, it doesn't even
have NPTL support. That means that scheduling of threads is
being done by user-space code. Yes, that results in really bad
scheduling latencies (on the order of 5-10ms in my experience).
You are right here (I'm disappointed about this myself). But AFAIK, no
code for the IP-Stack is done with userland threads. Why in fact do you
want to use userland threads ? In most applications (unfortunately not
in mine) it's better to use a "run to completion" paradigm instead of
doing a multithreaded userland application. Here again, the
hardware-multithreaded Ubicom CPU (and SDK) provides a perfect solution
for applications that ask for multithreaded development. As said, they
seem to be planning an implementation of SMP-Linux on top of this. Here
you'll have a realtime IP stack, Linux, and perfect thread scheduling,
but you'd need to use (and buy) their propriety SDK :(.
-Michael
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
