> This would also be helpful for people who want to be able to run
> multiple copies of the same RT task. At the recent RTLinux conference in
> Orlando I ran into a guy who was running engine simulations. He wanted to
> be able to run two copies of the same code at the same time and examine
> variables in each. Obviously if they are global variables (and they are),
> he will need some sort of namespace architecture to make this work. Has
> anyone given this any thought?
>
> Regards,
>
> Steve
Hi Steve -- that guy was me.
Not as yet having had any practical experience with RTL/RTAI, from what
I've seen so far they appear to be good solutions for small to
mid-sized control and data acquisition systems, where inputs and
outputs are known and fixed within the application. However, in
addition to control and data acquisition, our real-time simulation
systems need to:
1) run N number of user applications (simulations or control code
written in C and/or Fortran) in real-time, at different rates
(typically 5/10/20/50 msec), across multiple cpus (it would be nice if
Linux had a notion of real-time priorities, so the only component that
would have to run as a kernel module would be the frequency based
scheduler)
2) provide the user "on the fly" r/w access to any statically defined
parameter in any real-time user application, on any cpu for purposes
of display, access from within test scripts, or binding to i/o channels
3) need to provide a comprehensive namespace management scheme,
whereby multiple copies of a single executable (with different process
names like "left_engine" and "right_engine") may be run, and the user
is able to distinguish whether objects of the same name are one shared
object, or different objects
4) define/delete/modify i/o channel attributes and bindings to
parameters in simulation space, at any time
5) have a system that is self configuring at boot time -- i.e. no i/o
process code needs to change when more i/o boards are added/removed
6) scale from small applications - where the number of simulation
parameters are in the thousands, and the i/o channel counts are in the
hundreds; to large applications - where the the parameter count can be
greater than 100,000 and i/o points are greater than 2000
7) provide a utility to walk the elf/dwarf user applications and
extract parameter attributes of only the user defined static
parameters, such as program, module, common (f77) or C struct,
parameter name, parameter type, logical address, number of dimensions,
upper/lower bounds of each dimension, etc...
8) allow users to change their real-time applications without ever
having to change or re-link the user interface or i/o process
applications
We are doing all of this now on systems provided by Concurrent
Computer Corp (formally Harris Computer Systems).
One question I would like to ask for starters: Short of looking at
gdb source, how could I extract parameter attribute information from
executables (to build a symboltable) -- I don't seen any mention of
dwarf info as being available in RedHat 6.2 or 7.0. The "nm" utility
does not provide enough info.
--
Dean W. Anneser
Software Engineering Fellow
Real-Time Test Systems
Pratt & Whitney Aircraft
400 Main St., m.s. 161-05
East Hartford, CT 06108
email: [EMAIL PROTECTED]
phone: 860.565.9372 fax: 860.557.3482
"One test result is worth one thousand expert opinions" - Wernher von Braun
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
