From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C5D3724.1000908@domain.hid> Date: Sat, 07 Aug 2010 12:36:20 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4C5D0F40.1070104@domain.hid> <1DDE5D7F-58F5-4919-A4B4-5FCAD385E679@domain.hid> In-Reply-To: <1DDE5D7F-58F5-4919-A4B4-5FCAD385E679@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] migration scenario to xenomai List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Guenter Ebermann Cc: xenomai@xenomai.org Guenter Ebermann wrote: > Hi Gilles, > > Am 07.08.2010 um 09:46 schrieb Gilles Chanteperdrix: >> You can access hardware registers in user-space by mmaping the memory >> mapped ones with /dev/mem, or using iopl/ioperm and in[lwb]/out[lwb] for >> the old x86 I/O registers. > > Ok, thank you very much. I will look into using /dev/mem (we dont need x86 I/O > - we use powerpc arch). > >> However, if this can help for a first order port to Xenomai, >> implementing an RTDM driver later is better on the long run. By limiting >> the interface between the application and low-level code to a well >> defined interface, it will make it possible to use different >> applications with the same drivers, or use different hardware with the >> same application at will, things that are often hard when the low-level >> code is mixed with the application code. > > The xenomai RTDM API is made solely for kernel space, if i understood the docs > correctly? > > Yeah, I understand your point with generic interface and device driver > separation. And I really like the way this happens under linux/xenomai. I am > also willing to write new drivers which are usable by a broader public using > these design principles. But the communication stack I am gona use (AUTOSAR > FlexRay stack) does not follow them. AUTOSAR (www.autosar.org) specs defines > the Interfaces and layers of the whole communcation system for cars. It does > not involve kernel/userspace separation, but it also does not mix the low-level > code with application code. Low level code is only implemented in the device > drivers (CAN, LIN, FlexRay), but the interface to the upper level stack is not > generic (as in linux with device drivers) - it is different for each kind of > lower layer device (CAN, LIN, FlexRay) to gain the best performance from each > of them. Well, it looks to me like you can implement the interface between driver and user-space with standard posix interface (especially ioctl), and then implement the AUTOSAR interfaces as a user-space library relying on this posix interface. -- Gilles.