Le 08/02/2013 14:40, Jan Kiszka a écrit :
[re-adding the list]
On 2013-02-08 14:28, Stéphane LOS wrote:
Le 08/02/2013 12:28, Jan Kiszka a écrit :
On 2013-02-08 10:18, Gilles Chanteperdrix wrote:
On 02/08/2013 10:07 AM, Stéphane LOS wrote:
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 tried to explain why it may be better to create an RTDM driver, but in
this case this may not be the best option. The answer to your question
depends on what you have to do to implement the driver. As I said, if
you simply have to access MMIO registers, user-space may be fine, if you
have to handle interrupts kernel-space (so, RTDM) is preferable.
Are we talking about linux/drivers/uio/uio_cif.c here? That one
obviously has interrupt support.
If your customers may want to use Xenomai 3 with I-pipe instead of
Preempt-RT underneath (both options will exist), RTDM will still be
required for interrupt handling. If you like to, you could propose such
a driver for Xenomai integration. That would ensure it will come with
future releases.
I also wonder if it didn't make sense for us to provide an UIO-like
infrastructure for such use cases (single-user device drivers with IRQ
event channel needs).
Jan
I am talking about the new products based on the netX chip :
http://lxr.free-electrons.com/source/drivers/uio/uio_netx.c
Ah, I see. Structurally similar, though.
I have been through :
http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3
Looks like we should create an RTDM driver and build our Xenomai
specific libcifx on top of it.
Since the kernel now includes by default the UIO stuff, the board will
likely be detected twice, once by UIO and second by the RTDM driver.
Is it a problem ?
Should the user of the RTDM driver disable UIO / netX in the kernel ?
It's not problem to have multiple drivers registered for the same IDs.
You can always rebind them via sysfs or black-list one of them in the
local modprobe configuration.
Jan
Sorry for not posting to the list, wrong button pushed.
Thank you and Gilles for your answer.
I bet there will be more questions. Have a nice week end.
Best Regards,
Cordialement,
Stéphane LOS
[email protected]
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
