Re: [Xenomai] Hilscher driver for cifX boards

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.

-- 
                                                                Gilles.