Linux with RTAI: how would this work?

Hi,

Let's say I'm developing a control system for a UAV and I've decided to use Linux with RTAI in the vehicle. I have a real-time task which does the actual actuation of the flight surfaces and it controls the hardware (motors) through GPIO pins. The RT task is talking to Linux through a fifo (which Linux processes see as a block device) and Linux has a device driver for a wireless radio data transceiver to talk to the base station.

The problem I see is that data being fed to the RT task is non-deterministic since the data comes from Linux. This implies that to get proper hard Real Time response one would have to write a RT device driver for the wireless data transceier as well. In other words, the use of Linux wouldn't really help very much. Even in a factory setting where the UI updates are being handled by Linux there would still need to be a RT Ethernet driver to talk to other factory floor devices for the same reason as illustrated above.

So is RT Linux actually a good choice?

JR

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Jim Relsh
Loading thread data ...

Jim Relsh kirjoitti:

My experience with regular linux and realtime processes is that everything that needs hard realtime must be in the realtime process, and if you give control back to the kernel by eg. calling RTC, you must have a very light normal application that does not cause heap fragmentation, otherwise there will be defragmentation. The defragmentation may take tens of milliseconds.

I have not used RTAI but I assume that if you have hard realtime requirements, all critical parts must be inside the RT processes, even the device drivers.

Mikael

Reply to
Mikael Nordman

"Mikael Nordman" schreef in bericht news:Qaa4j.259695$ snipped-for-privacy@reader1.news.saunalahti.fi...

Exactly my point! What's the use of RT Linux in that case?

I'm wondering if eCos isn't much better suited for my application than RT Linux since both the drivers and the kernel are hard Real Time, there would be no duplication of effort.

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Jim Relsh

In your case you may not need RT Linux.

RT Linux is good where you have some complicated, non-critical stuff going on (as a batch process where the batch commands come in through Linux, or Linux is managing a bunch of different profiles), plus you have real time stuff.

If all you're doing is receiving radio commands and controlling surfaces, then maybe you're right.

Reply to
Tim Wescott

--snip--

Its good for sales terminal or device where you always know the input. But in this case we have few motors for pan and tilt moving same time with radio receive/send commands. So, I would prefer a non-preemptive behavior to do the job. Certainly, I will consider task priority very critically to make sure my motors move to right direction as commanded by radio receiver ;-)

All RFID readers to that trick, for example talkin to access control.

ali

Reply to
Ali

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.