LXRT (was: Introduction to RT-Linux)

J

Thread Starter

Jiri Baum

Jiri:
> > To do user-space hard RT, you'd need to make sure the entire linux
> > kernel is up to it; which is why most user-space RT is soft-RT.)

Robert:
> LXRT
...
> it seems to have some kind of a realtime "server" module which is the
> backend for the userspace process, which definitely is hard realtime
...

Sounds very good.

Do you have any more information/experience with this? If we can get userspace hard-RT, that would solve all the problems with partitioning RT and non-RT tasks... (For instance, it'd allow priority inheritance, which would mean that hard-RT, soft-RT and non-RT tasks could all safely run
against the same MAT core. That alone would save a world of hassle.)


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello guys,

I dismissed the LXRT as being viable based on an early research of it several months ago. Early on it was simply a means of using the RTAI API form within user space, aiding development and debug of kernel modules by doign the brunt of the debug from user land.That didn't impress me too much because all of my dangerous kernel module code was worked out, so I moved on and continued using RTLinux.

Your discussions prompted me to pour through some RTAI documentation and I decided it was worth downloading the source for it. It does appear that hard real time can be brought to user land with a few exceptions (some API calls aren't available yet, etc and I think a lot of Linux blocking calls are out of the question). They claim the cost of user space RT vs. kernel module RT is a few extra microseconds. One other limitation from what I understand is that there is some significant overhead in creating and ending RT tasks, which is *probably* not a big deal with most folks who are creating processes in a startup function of some sort. It appears the only real difference in a RT thread and a user thread is a function call or two, in which case it can be optionally compiled in with preprocessor directives.

What I am not sure of is your programming model really a multithreaded app now ?? Specifically, do you get the simple global shared memory between RT priority threads and user land threads (as you would in a POSIX pthread implementation) ?

I will talk to my employer about contributing the IO source code that I developed for my kernel modules. It isn't anything great, but it is better than writing a driver from scratch. Basically the file sets up data structures for each IP module that can be installed in a carrier board. I am only using 48 bit IO modules, two of which can be installed into a Compact PCI carrier card. I am configuring the board to have the first 32 bits as inputs and the last 16 bits as outputs. That just turns out to be a good ratio for our IO division here at my company. what you have after running the init_dio_modules are "n" number of data structures containing information about the module and the IO image. I thne have a function that copies the internal data representation to the actual ports. You guys will probably find a better way to integrate it into your project I am sure, but this would be a starting point. I would like to eventually add support for additional Industry pack modules (ADC, DAC, etc..) but the digital IO was most essential.

So has anyone actually used LXRT with RTAI and gotten any performance benchmarks? Has anyone hooked an O-Scope up to a port and seen what the max jitter and latencies are??

~Ken


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

Hi Jiri,

On Fri, 28 Sep 2001, Jiri Baum wrote:
> Do you have any more information/experience with this?

Unfortunately not. The whole LXRT stuff was completely reorganized recently and there's not much documentation at the moment (but the RTAI
team is working hard to improve that). Nevertheless, there are some examples in the package which could give you an impression. Just download the RTAI packet for your kernel from (link on http://www.rtai.org) and install it according to the README.QUICKINSTALL file (should be straight forward - all kernels up to 2.4.9 and 2.2.19 are supported).

However, there was recently a success report of running the Matlab Simulink/RealTimeWorkshop ontop of RTAI/LXRT

I'll tell you if I've found out more about how it works.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top