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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
