From: "Stéphane LOS" <slos@hilscher.com>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] Hilscher driver for cifX boards
Date: Fri, 08 Feb 2013 10:07:39 +0100 [thread overview]
Message-ID: <5114C05B.7040507@hilscher.com> (raw)
In-Reply-To: <5113D225.8030900@xenomai.org>
Le 07/02/2013 17:11, Gilles Chanteperdrix a écrit :
> On 02/07/2013 03:53 PM, Stéphane LOS wrote:
>
>> Hello Sirs,
>>
>> Hilscher is offering a Linux driver based on UIO for cifX boards.
>>
>> In my understanding, down to 1ms cycle time, a PREEMPT RT solution
>> should be enough.
>>
>> The cifX boards can manage with bus cycle times down to 250µs like with
>> EtherCAT or Sercos III firmwares.
>>
>> So it seems in that cases that using Xenomai would be the way to go.
>> I suppose that it would be needed to modify or change the existing
>> driver but I can't figure out how things (Xenomai / RTDM / UIO) fit
>> together.
>>
>> UIO is the kernel module that allows the mapping of the board memory to
>> user space.
>>
>> The cifX driver uses the libpciaccess to pick up the board and retrieve
>> some board information from UIO before the mapping.
>> Then it uses pthread and rt functions when accessing the board.
>>
>> Since UIO and libpciaccess are only used during the initialization, is
>> it a problem for a Xenomai application ?
>>
>> We have setup a Xenomai system and tried to compile the user land
>> library with Xenomai options and flags and it seems we have been successful.
>> The driver should be using the POSIX skin of Xenomai if we have been lucky.
>>
>> I can't see why we would need RTDM. Any hint please ?
>>
>> I am an absolute beginner in the Xenomai arena, don't throw me to the
>> lions...
>>
>
> If UIO is used to register an interrupt handler for instance, the
> interrupt handler will not be called in real-time context when used with
> Xenomai, so, you would have to use the (deprecated) native or posix skin
> services to register a user-space interrupt handler, or more likely
> write an RTDM driver. On the other hand, if what you need is simply
> accessing the board registers through MMIO, then you do not need RTDM.
>
> While accessing registers from user-space may be tempting, there is a
> risk of ending up with an application where the driver code is not
> clearly separated. Writing a driver separated from the application is
> preferable, as it provides a sane isolation between the two. If you
> change the hardware, you just have to rewrite a driver which follows the
> same profile, if you want to write another application using the same
> driver, you can keep the driver.
>
Thank you for your kind support Gilles.
The cifX Device Driver is Hilscher's library to deal with cifX boards
and is available for the major OSes.
Additionally it is available to anybody as source code, the cifX Driver
Toolkit when one has to create a driver for his own OS.
This driver library accesses the board interface which is a Dual Port
Memory.
So the user application shall use this layer and gets independence from
the target OS.
I understand that we should create an RTDM driver instead of a UIO
driver and adapt the user library so that it uses the RTDM driver.
Am I right ?
I have seen also the Xenomai Solo project and the upcoming Xenomai 3
that would be using vanilla kernel with PREEMPT RT.
When this happens, would our RTDM based cifX driver still be an option
or would the UIO based driver suffice ?
Best Regards,
Cordialement,
Stéphane LOS
slos@hilscher.com
Support technique
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hilscher France
12, rue du 35ème Régiment d'Aviation
Miniparc du Chêne
69500 BRON
France
Tél. : +33 (0) 4 72 37 98 40
Fax : +33 (0) 4 78 26 83 27
http ://www.hilscher.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
next prev parent reply other threads:[~2013-02-08 9:07 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 14:53 [Xenomai] Hilscher driver for cifX boards Stéphane LOS
2013-02-07 16:11 ` Gilles Chanteperdrix
2013-02-08 9:07 ` Stéphane LOS [this message]
2013-02-08 9:18 ` Gilles Chanteperdrix
2013-02-08 11:28 ` Jan Kiszka
2013-02-08 11:35 ` Gilles Chanteperdrix
2013-02-08 11:46 ` Jan Kiszka
[not found] ` <5114FD7B.20902@hilscher.com>
2013-02-08 13:40 ` Jan Kiszka
2013-02-08 14:33 ` Stéphane LOS
-- strict thread matches above, loose matches on Subject: below --
2013-02-12 11:37 Stéphane LOS
2013-02-12 11:51 ` Jan Kiszka
2013-02-13 14:09 ` Stéphane LOS
2013-02-14 13:36 ` Stéphane LOS
2013-02-14 15:01 ` Stéphane LOS
2013-02-15 14:54 ` Jan Kiszka
2013-02-18 11:43 ` Stéphane LOS
2013-02-26 9:29 Jerome Poncin
2013-02-26 11:37 ` Jan Kiszka
2013-02-26 14:25 ` Jerome Poncin
2013-02-26 14:28 ` Jan Kiszka
2013-02-28 8:15 ` Jerome Poncin
2013-02-28 11:31 ` Jan Kiszka
2013-02-28 12:08 ` Jerome Poncin
2013-03-01 13:56 ` Jerome Poncin
2013-03-01 17:02 ` Jan Kiszka
2013-03-01 20:06 ` Gilles Chanteperdrix
2013-03-04 9:13 ` Jerome Poncin
2013-03-04 21:08 ` Gilles Chanteperdrix
2013-03-05 10:45 ` Jerome Poncin
2013-03-05 11:26 ` Jan Kiszka
2013-03-05 12:21 ` Gilles Chanteperdrix
2013-03-05 12:30 ` Gilles Chanteperdrix
2013-03-05 15:42 ` Jerome Poncin
2013-03-05 19:41 ` Gilles Chanteperdrix
2013-03-06 8:10 ` Jerome Poncin
2013-03-06 8:19 ` Gilles Chanteperdrix
2013-03-06 8:55 ` Jerome Poncin
2013-03-06 10:33 ` Jerome Poncin
2013-03-06 12:04 ` Gilles Chanteperdrix
2013-03-06 13:58 ` Jerome Poncin
2013-03-06 15:28 ` Jan Kiszka
2013-03-06 21:05 ` Gilles Chanteperdrix
2013-03-07 15:33 ` Jerome Poncin
2013-03-08 10:17 ` Jerome Poncin
2013-03-08 12:22 ` Gilles Chanteperdrix
2013-03-12 9:10 ` Jerome Poncin
2013-03-12 12:21 ` Gilles Chanteperdrix
2013-03-12 15:27 ` Jerome Poncin
2013-03-12 19:38 ` Gilles Chanteperdrix
2013-03-13 11:08 ` Jerome Poncin
2013-03-15 9:09 ` Jerome Poncin
2013-03-15 11:07 ` Jan Kiszka
2013-03-15 13:04 ` Jerome Poncin
2013-03-15 13:24 ` Jan Kiszka
2013-03-18 10:02 ` Jerome Poncin
2013-03-19 13:42 ` Jerome Poncin
2013-03-06 20:42 ` Gilles Chanteperdrix
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=5114C05B.7040507@hilscher.com \
--to=slos@hilscher.com \
--cc=gilles.chanteperdrix@xenomai.org \
--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.