Xenomai:Porting From RTOS

From Xenomai

Jump to: navigation, search

Unfortunately, there is no written guidelines for porting from other RTOSes like VxWorks/pSOS to Linux using Xenomai, yet. So here is some introductory information about this topic:

  1. The VxWorks and pSOS emulators are built over Xenomai's abstract RTOS core, the same way the POSIX API is. In other words, no API has special privilege over other existing APIs, including the so-called "native" one. For this reason, the following documentation is worth reading, even if the API concerned is the native one: the general principles will remain the same for any supported API.
  2. Both pSOS and VxWorks APIs allow for kernel and user-space programming. I would really recommend that user-space programming be preferred, since the latency gap between both spaces is small, especially on x86 hardware where MMU context switching is relatively cheap. For that reason, ease-of-use of the user-space programming model outweighs by far any gain in terms of WCET one could expect from running the application directly from kernel space. For instance, the worst-case latency observed on a (sane) P-III 750Mhz is typically in the 17-22 us range in kernel space, compared to 20-25 us in user-space. However, user-space brings memory protection and GDB support to debug real-time applications with Xenomai.
  3. If the bulk of the application should be implemented in user-space, parts of such application could still be hosted in kernel space, depending on the architecture you want to build. A typical case concerns I/O drivers (see #5) built over the RTDM layer.
  4. It is possible to mix several APIs in a single real-time executable in user-space. Sometimes it is useful to get additional functionalities the original API does not provide. For instance, shared memory is not directly available from the emulated pSOS or VxWorks APIs, but one may use them along the POSIX API to get such support.
  5. Real-time I/O drivers should be implemented using the RTDM layer, which allows for predictable and ultra-low latencies regarding interrupt handling and task activation, and attempts to follow the usual Linux driver model as closely as possible. It is possible to keep I/O manipulation strictly in user-space with Xenomai, e.g. using MMIO like it is possible under the vanilla Linux environment. Xenomai keeps all those options open. However, the RTDM layer should definitely be preferred for implementing the kernel-based portion of any real-time capable driver (Xenomai API Documentation), instead of going for some ad hoc implementation. RTDM is heavily used in large applications right now, and is being ported to PREEMPT_RT, which would keep your options open for moving to native preemption if you decide so, once this technology is stable enough.
  6. The requirement for I/O drivers exhibiting deterministic latencies in the original application should be examined anew, in the context of the Linux port. Sometimes this requirement may be relaxed, in which case those drivers should rather be implemented as plain Linux character device drivers. Xenomai allows a user-space application to switch back and forth from real-time context to plain Linux context seamlessly, at the expense of a loss of predictability when running over the plain Linux domain though.
  7. Xenomai emulates the system calls from the core APIs of traditional RTOSes like pSOS and VxWorks. Here is the list of the emulated calls (note: a few among those calls are only available from kernel space, like those involving callouts from the kernel-based scheduler for instance, but the vast majority is available from either contexts):

VxWorks

taskSpawn, taskInit, taskActivate, taskDelete, taskDeleteForce, taskSuspend, taskResume, taskPrioritySet, taskPriorityGet, taskLock, taskUnlock, taskIdSelf, taskSafe, taskUnsafe, taskDelay, taskIdVerify, taskTcb, taskRestart taskCreateHookAdd, taskCreateHookDelete, taskSwitchHookAdd, taskSwitchHookDelete taskDeleteHookAdd, taskDeleteHookDelete taskName, taskNameToId, taskIdDefault, taskIsReady, taskIsSuspended semGive, semTake, semFlush, semDelete, semBCreate, semMCreate, semCCreate wdCreate, wdDelete, wdStart, wdCancel msgQCreate, msgQDelete, msgQNumMsgs, msgQReceive, msgQSend intContext, intCount, intLevelSet, intLock, intUnlock sysClkConnect, sysClkDisable, sysClkEnable, sysClkRateGet, sysClkRateSet tickAnnounce, tickGet, tickSet kernelTimeSlice, kernelVersion printErrno, errnoSet, errnoGet, errnoOfTaskGet, errnoOfTaskSet

pSOS+

as_catch, as_send, as_return ev_receive, ev_send pt_create, pt_delete, pt_getbuf, pt_ident, pt_retbuf q_broadcast, q_create, q_delete, q_ident, q_receive, q_send, q_urgent q_vcreate, q_vdelete, q_vident, q_vreceive, q_vsend, q_vurgent, q_vbroadcast rn_create, rn_delete, rn_getseg, rn_ident, rn_retseg sm_create, sm_delete, sm_ident, sm_p, sm_v t_create, t_delete, t_getreg, t_ident, t_mode, t_restart, t_resume, t_setpri, t_setreg, t_start, t_suspend, tm_cancel, tm_evafter, tm_evevery, tm_evwhen, tm_get, tm_set, tm_tick, tm_wkafter, tm_wkwhen i_return, k_fatal

(courtesy Philippe Gerum, 26 Feb 2007)

Personal tools