From: Leopold Palomo Avellaneda <leo@domain.hid>
To: xenomai@xenomai.org
Subject: [Xenomai-help] OT. A question about constraints in realtime
Date: Tue, 15 Jul 2008 23:46:17 +0200 [thread overview]
Message-ID: <200807152346.21863.leo@domain.hid> (raw)
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
Dear people,
first of all this is an Off topic, so please don't be angry with me. If you
don't want to answer, move this message to /dev/null. But I have a problem
with a device and maybe some people in this list could give me some idea.
I'm working in a robotics lab and we have a device (a haptic from Sensable)
that it's connected to the parallel port. Of course that the Sensable company
doesn't not publish open source drivers, etc. By now it's an sterile
discussion.
Anyway, they provide a driver that it's a lib (.so). Also there's some library
that can act with the device using that driver. Excepting the driver, for the
other parts I have some source code.
I have had several problems with this driver. Firstly, the driver only can
works if the parport module detects the EPP mode. Sadly, the linux parport
module is more or less unmaintained and fails in many boxes to detect the EPP
mode, although the bios is configured to.
After that, you can read encoders of the device (using the driver) but when
you send forces to the engines, it suffers some kind of chattering and the
driver disable the force because the loop of control expend too much time.
Asking in some forum I have arrived to the conclusion that the driver has some
kind of timer and if it doesn't not receive any order in 1ms, then the force
is disabled.
So, my question are:
- Why the windows driver works so well? the scheduler in Windows do that if a
task need to have a constraint of 1ms they give it the control and that's
all?
- Why a linux driver doesn't not work? the load of the box is quiet normal.
I'm not compiling or solving eigen systems. Or is possible that some device
is breaking some access to the parport, or whatever?
- I have tried to use the realtime kernel -rt but same result.
- Can I do something with xenomai to avoid it?
The sensable people claims that their driver works with some versions of Linux
(till fedora 4 and some suse) but I'm not be able to run it in a debian etch.
I don't know if the distros provide a kernel with some kind of modifications
that solve it, but I don't think so.
Well, thanks in advance and I'm sorry for the noise. Really, the realtime
stuff is something not obvious...
Best regards,
Leo
--
--
Linux User 152692
PGP: 0xF944807E
Catalonia
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next reply other threads:[~2008-07-15 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 21:46 Leopold Palomo Avellaneda [this message]
2008-07-28 10:07 ` [Xenomai-help] OT. A question about constraints in realtime Gilles Chanteperdrix
2008-07-29 22:08 ` Leopold Palomo Avellaneda
2008-07-29 22:23 ` Gilles Chanteperdrix
2008-07-29 22:39 ` Leopold Palomo Avellaneda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200807152346.21863.leo@domain.hid \
--to=leo@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.