[Xenomai] xenomai 3 migration bitmask for calls

Philippe Gerum rpm at xenomai.org
Wed Oct 18 18:57:47 CEST 2017


On 10/18/2017 08:50 AM, Marco Camurri wrote:
> Dear all,
> I'm migrating a mission critical system based on the native skin of
> Xenomai 2 to Xenomai 3.
> 
> I read from the migration guide that now this skin is called Alchemy,
> therefore I did the modification in header includes and other things.
> 
> However, some bitmask variables some xenomai calls have been removed.
> I would like to replicate the exact behavior I had on Xenomai 2
> in the new system.
> In particular, the calls I have in the previous system are:
> 
> 1) rt_task_spawn(&servo_ptr, name, servo_stack_size, servo_priority,
>                  T_FPU | T_JOINABLE | T_CPU(cpuID), motor_servo, NULL)
> 
>    T_FPU and T_CPU are removed, who do I make the new call?
>    Just with T_JOINABLE?

T_FPU was dropped since any userland thread has fpu enabled implicitly
(even in 2.6). So omitting it brings no change.

T_CPU() should be replaced by an explicit call to rt_task_set_affinity().

> 
> 2) rt_heap_create(&heap,name,(size_t)(elemNum*elemSize), H_SHARED)
> 
>    H_SHARED has been removed.

Heaps shared between kernel and userland apps should be implemented by a
memory mapping instantiated by a RTDM driver.

If sharing is between userland processes, then you only need to pass
--enable-pshared when configuring userland libs for build, then specify
a common session name (--session=<name>) when starting any process which
should have access to shared resources (i.e. including those heaps). Or
you can create a POSIX shared memory segment over tmpfs directly.

>    The only options I have now are: H_FIFO, H_PRIO, H_SINGLE.
>    What should I choose?
> 

Depends on what you need:
http://www.xenomai.org/documentation/xenomai-3/html/xeno3prm/group__alchemy__heap.html#ga1d19ad24dc9f94b969aa0f574170bdc4

> 3) rt_timer_set_mode((RTIME) TM_ONESHOT)
> 
>    TM_ONESHOT does not exist anymore.  What should I set in the
>    rt_set_mode function?
>    The documentation only says to set 0 for no op, but it does not tell
>    anything about the other options.

As mentioned in the migration guide, that call is obsolete, there is no
other option, you don't need it. Oneshot timing is the default, use
--alchemy-clock-resolution=<ns> to turn on periodic ticking for the
application process.

-- 
Philippe.



More information about the Xenomai mailing list