Introduction to RT-Linux (fwd)

J

Thread Starter

Jiri Baum

Those of us in Melbourne, Australia, might be interested in this talk... (LUV is the Linux Users of [the state] Victoria; membership is free, no-one will mind if you just turn up.)

See you there!

Jiri
----- Forwarded message from Graeme Cross <[email protected]> -----

From: Graeme Cross <[email protected]>
Subject: September Programmer's SIG meeting
To: LUV Announcements <[email protected]>,
LUV Programmers SIG <[email protected]>
Reply-To: [email protected]
X-Virus-Scanned: by AMaViS perl-11

The next LUV Programmers SIG meeting is on Tuesday September 25.

The topic will be "Introduction to RT-Linux" by Scott Thomson.

What is RTLinux?
How does RTLinux work?
How is RTLinux used?
Licensing
Support & training
Usage examples

Everyone is welcome to the meeting, which is at:

7pm, Tuesday, September 25
MyInternet
Level 8, Blackwood House
14-20 Blackwood Street, North Melbourne

Blackwood Street is the first on the left on Flemington Road, near the Royal Melbourne Hospital.

We will be going for dinner afterwards at La Porchetta near the Queen Victoria market.

The planned talks for upcoming Programmers SIG meetings are:

Oct 23: "Simple multimedia programming with SDL", Anthony Kruize
Nov 27: "Postscript programming", Malcolm Herbert
Dec : No meeting

--
Graeme Cross <[email protected]>
-
To unsubscribe send 'unsubscribe programmers-sig' to [email protected]

----- End forwarded message -----

--
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

 
A few observations as far as relevance to MAT is concerned:

- User-space tasks can't inherit hard-RT priority, so they cannot interface to the same MAT core as the RT tasks.

This would mean that most likely the computer would end up running two separate MATs - one in RT doing the control, and another in userspace handling lower priority tasks, with some sort of protocol between them.

(For instance, it'd probably be unrealistic to have the GUI real-time.)

- The situation with porting SysV IPC calls to RTLinux was not cleared up.

However, it's not likely to be a major problem.

- Licensing was not cleared up (at least to me), needs further investigation.


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
 
I wrote:
> Those of us in Melbourne, Australia, might be interested in this talk...
...
> The topic will be "Introduction to RT-Linux" by Scott Thomson.

Okay, I went there and took some notes...

RTLinux is its own OS, runs Linux as lowest priority task, completely pre-emptably - normal tools can run there, scripting, GUI, whatever. It
intercepts all interrupts (and passes them on to normal Linux if/when appropriate).

Real-time processes are kernel modules.

The diagram looks a bit like this: HW interacts with RTLinux, which runs some RT processes and plain Linux. The plain Linux then runs user-space
processes as normal.

Programming for RTLinux:

- kernel patch

- the module has an entry routine, which gets called at startup and
sets up everything. It can register tasks for periodic execution
and/or as interrupt handlers, very simply.

- comms with user space is done via FIFO (/dev/rtf0, rtf1 etc), shared
memory, signals

Licensing:

- patented

- can be freely used under the GPL - if unchanged??? Scott left this
topic rather quickly.

FSM labs provides commercial support, other than that there's the usual mailing lists etc.

www.rtlinux.org and www.rtlinux.com

I asked a question about SysV IPCs, but Scott didn't know what the situation/equivalent was.

Timing guarantees:
- periodic tasks at 35us
- interrupts within 15us
- these are apparently hampered by the ISA bus; PowerPC and Alpha are
supposed to be a fair bit better, even just an SMP board better at
periodic tasks

Three examples:

- 50kHz square wave generator (20us periodic task) on parallel port
hooked up to an oscilloscope

- servo controller, bit-banging both PWM and the quadrature input,
polled by a periodic task. This was done by a three-task setup: a
20kHz task doing the actual bit-banging, a 100Hz command task
accepting commands and doing the actual control (including evaluating
torque and position), and a 20Hz task to send info back to user space

- stepper controller, which is actually simpler because there's no
feedback. The command task does acceleration-limiting to avoid
exceeding stepper specs.


The system crashed once, on an rmmod; that could've been the fault of standard rmmod or rtlinux. Sure was strange to see a bluescreen, though.

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
 
R

Robert Schwebel

On Wed, 26 Sep 2001, Jiri Baum wrote:
> - User-space tasks can't inherit hard-RT priority, so they cannot
> interface to the same MAT core as the RT tasks.

Did you look at RTAI's LXRT stuff? It does hard realtime in user space.

> - Licensing was not cleared up (at least to me), needs further
> investigation.

The license is currently changing, as the FSF has found some GPL inconsistencies. You should wait with further investigations until the new license is out.

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
 
Jiri:
> > - User-space tasks can't inherit hard-RT priority, so they cannot
> > interface to the same MAT core as the RT tasks.

Robert:
> Did you look at RTAI's LXRT stuff? It does hard realtime in user space.

Nope - this was my report of a talk I went to here in Melbourne, about RTLinux.

(Their argument is that by keeping their custom kernel small, it's easier to do hard RT, preempting the normal kernel. 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.)

> > - Licensing was not cleared up (at least to me), needs further
> > investigation.

> The license is currently changing, as the FSF has found some GPL
> inconsistencies. You should wait with further investigations until the
> new license is out.

It's not just the copyright, there's also a patent in there.


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
 
Top