Hello Tobias (or anyone else),
As I said before, I am in study phase of a project which ports
our motion package to RTLinux.
It is a library of motion related functions, used by an OEM to create his
application.
All the library function calls must be possible from the same application,
in this case the RTLinux application created by the OEM customer who uses
our library.
The library is already ported to various realtime and non realtime operating
systems:
OS-9, PSOS+, OS/2, WINDOWS-NT, WINDOWS-CE.
The porting to RTLinux should not require a drastic change to our software
architecture.
Now on RTLinux I have various problems which are not obvious to solve:
1) We have a function to connect to a motor (joint) and returns the axis ID,
compare with fopen which returns a file pointer. Inside this function
many things
happen:
- Open the device-driver
- Allocate some memory using malloc
- Create/Open various OS resources (shared memory, semaphores, events,
mutexes)
- start a event handler thread for the joint.
- this function and all other user functions (about 100) use the FPU.
Problem 1) With the other OS, it does not matter wether we
are in the context of a thread or the context of main
(init_module).
With RT-Linux it seems to be possible to allocate memory and
create
system resources only in the context of init_module.
Is there some kind of work-around to overcome this
problem?
2) We have a function which initializes a joint,
this means reading a text file with about 60 parameters and send them to
the hardware device.
Problem 2) With other OS it is no problem to read a file,
how do we handle this in RT-Linux, has somebody implemented
file access for RTLinux?
3) Our library is quite big, aqbout 30 thousand lines of C-code, therefore
we need
good tools for debugging in kernel mode and RT-Tread mode, can anybody
give advice,
which are the best tools, free or comercial, no problem.
There are some more problems which makes porting to realtime linux
difficult,
but these are the most important for now.
Any help/advice is greatly appreciated.
Regards,
Bert Eding
Nyquist Industrial Control
-----Original Message-----
From: Tobias Klotz [mailto:[EMAIL PROTECTED]]
Sent: dinsdag 20 juni 2000 10:39
To: Eding, Bert
Subject: Re: [rtl] Floating point in "restricted" code
Hello,
we are currently doing a robotics project with RTLinux (2.0) and we are
using
FP.
The thing is that you can't use it in
1) init_module / cleanup_module
2) irq-handler
we use a hardware giving us a 5ms trigger and the ISR just is used to wakeup
a
thread (in this thread FP is allowed (by explicitly allowing it)
questions? just ask, it is not that complicated (on the first look on second
it`s as complicated as realtime is by nature...)
tobias
"Eding, Bert" schrieb:
> Hello,
>
> I am very new to RT-Linux and I was following your FP-discussions.
> I notice that You want to avoid this functionality in kernel mode.
> I am curently in study fase to see if our motion-controller/robotics
> package can be ported to RT-Linux.
> In general, a robot controller package uses lots and lots of FPU
> calculations,
> also during initialisation.
> I would say that this this kind of applications is a typical RT
application.
> So, please export the fp save and restore functions in the future.
>
> Regards,
> Bert Eding
> Nyquist Industrial Control.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: maandag 19 juni 2000 21:25
> To: Shel Hoffman
> Cc: rtlinux
> Subject: Re: [rtl] Floating point in "restricted" code
>
> On Mon, Jun 19, 2000 at 11:29:57AM -0500, Shel Hoffman wrote:
> > Under what circumstance is it acceptable to use floating point (FPU) in:
> >
> > . a interrupt service routine?
>
> nope.
> >
> > . a RT-FIFO handler that is called when a FIFO has data added to it?
> > (e.g., a FIFO handler function specified rtf_create_handler())
>
> no.
>
> >
> > Would it make some sense to provide functions that save/restore the
> > FPU state so that an RTLinux application developer could use the FPU
> > in "restricted" places:
> >
> > init_module() // FPU can't normally be
used
> here
> > {
> > FPP_STATE state;
> >
> > rtl_save_fpp_state(&state); // Preserve FPU state
> >
> > // Use floating point here
> >
> > rtl_restore_fpp_state(&state); // Restore FPU state
> > }
> >
>
> These functions are in i386/switch.c in the V2 distribution. We have not
> exported them to
> the general purpose API because it complicates the API and doesn't seem to
> add utility.
>
> Here's the line of thought:
> 1. Saving fp state is _slow_ so you don't need it in an ISR -- there is
no
> performance loss
> in having the ISR hand over work to a thread.
> 2. Linux kernel code should follow Linux coding conventions so since use
of
> FP is fobidden in
> Linux kernel code, RTL assumes that parts of applications that run
under
> Linux kernel
> are going to not use FP.
> These components can ask RT threads or Linux user processes to do FP
> computations.
> 3. Rare workarounds are better than rarely used features. Keeping the API
> simple is
> critical.
>
> Furthermore: I'm very concerned about FP in alternative architectures. I
> would like RTL applications
> to run transparently in PPC, MIPS, Alpha, ia32,ia64 and some other
upcoming
> architectures.
> What's going to happen on a ia64 to code that does
> save fp // which means wait many cycles until the last of
> God knows how many
> fp instructions complete and the fp pipeline
clears
> do a couple of ops
> restore fp // which means wait until our ops all complete
> so that we
> // don't get failure interrupts after we have
> switched to
> // another thread.
>
> FP is dangerous, scary, frightening, stuff. It is only barely compatible
> with RT, and
> is really dubious outside of an RT thread.
>
> What do you think?
>
> --
> ---------------------------------------------------------
> Victor Yodaiken
> FSMLabs: www.fsmlabs.com www.rtlinux.com
> FSMLabs is a servicemark and a service of
> VJY Associates L.L.C, New Mexico.
>
> -- [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/
> -- [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/
-- [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/
