Grant Edwards wrote: > > or do the hard realtime stuff in hardware (if same can be > > reduced to very simple functions). > > 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'm surprised nobody has mentioned the real-time Linux patches :-) Specifically the PREEMPT_RT tree. The advantage of their method is that RT processes have access to all the normal Linux features - in kernel space and userspace. You lose the RT aspect temporarily while you do something that you couldn't expect to be RT anyway, like read a file, or a pipe waiting for a non-RT process, but at least you can do those things when its useful, and get RT properties when you're not doing such things. With network prioritisation and the experimental process-context TCP stack (which is not in the kernel), you might realistically be able to reply to a message over TCP with RT timing. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
