FAQ


On what hardware does Xenomai run?

Embedded hardware, desktop, server. This said, Xenomai has a strong focus on embedded systems, and most Xenomai ports nowadays target those platforms.

See the embedded hardware list, and the other-hardware list.


Is my embedded setup supported by Xenomai?

See the embedded hardware list.

If your board is not listed above, you may want to get more information from the Xenomai mailing list.

If you are willing to port Xenomai to an ARM-based system, you may want to have a look at this document.


What is this I-pipe thing? And what about Adeos? Are they related?

In Xenomai parlance, the I-pipe and Adeos both refer to the very same code, that makes a Linux kernel able to host a secondary kernel exhibiting real-time properties (e.g. Xenomai), on the same hardware.

This code is a kernel patch applied to a regular Linux kernel, which among other services, guarantees delivery of external interrupts to Xenomai with very low latency.

Note

You need the I-Pipe only for running Xenomai in a dual kernel configuration, i.e. over the Cobalt core.

Which I-pipe patch should I use with Xenomai version X on platform Y?

First of all, check there for an I-pipe patch which best fits your kernel.


What is a Xenomai skin?

To understand that, you should first know that Xenomai is some sort of Chameleon RTOS at its core, which can export multiple real-time APIs to applications, all built over the Xenomai nucleus.

A Xenomai API can impersonate an existing traditional RTOS interface such as VxWorks ™, or provide an original programming interface for some particular purpose, such as RTDM.

Basically, each API makes Xenomai look a different RTOS albeit all of them are based on the same common core. This is the reason why we call an implementation of such API, a Xenomai skin.


Can I still use GDB in a dual kernel configuration?

Yes, definitely. Debugging a Xenomai application in a dual kernel system is no different from debugging any regular application.

Note

The only side-effect of using GDB for debugging a Xenomai application is that breakpointing and single-stepping implies a switch to secondary mode (i.e. threads are automatically handed over the Linux kernel as soon as GDB regains control).

I ran into a technical issue which is not covered here

Please have a look at the knowledge base.

Comments are closed