Re: [Xenomai-help] Reading Memory Mapped IO

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

Doyle, Alan wrote:
> Hi,
> 
> I have an application where I need to read four contiguous memory mapped
> data registers in response to an interrupt. As its real time critical I
> intend to implement the read in Xenomai. Having read and processed the
> data it later needs to be passed to a Linux domain application, I am
> hoping to use a Posix message queue for this purpose.
> 
> I seem to have two options as to how to implement this, I could register
> the interrupt in a Xenomai user space thread and mmap the data registers
> so that on receiving the interrupt the registers could be read.
> Alternatively I could write a Xenomai RTDM driver to read the registers
> on interrupt and use the driver read call from the Xenomai user space
> thread to access register data. In each case the data would then be
> passed to the Linux domain via a message to a Posix queue - after some
> further processing that is not real time critical.
> 
> Could you enlighten me as to the pros and cons of each approach, I am
> particularly unclear as to the implications of using mmap in the Xenomai
> domain and what if any affect it might have on the real time
> responsiveness (I understand mmap() to be a call back into the Linux
> kernel rather than to the Xenomai nucleus).

To call mmap from real-time code is actually a generic issue. If you
look at the design of other time-critical, though not hard-RT drivers
like video4linux, they also try to avoid mmap'ing on demand. Instead one
should set up mappings ahead-of-time during device initialisation. Use
rings of premapped buffers that cycle between the driver and the
application.

Unless you have really specific requirements, going the RTDM path has
the advantage of introducing a clear abstraction between the hardware
accessing driver and some application. If you happen to reuse your
hardware for a different project later, you will then be able to reuse
the driver as well.

Your application could become a multi-threaded Xenomai program: one
thread accessing the RTDM device under strict time constraints and
pushing information into the message queue, some other thread(s)
(SCHED_OTHER, but mapped to Xenomai) reading the queue under primary
mode and handling the data under secondary mode like a normal Linux
thread. If you can isolate all time critical work in the driver, you may
even access the device directly from the second thread, making the first
one obsolete.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]