[Xenomai-help] General questions

[Xenomai-help] General questions

[Urs.Eichholzer]

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

Hi all,
 
We have some general questions
 
Our setup is:
Hardware MPC5200B on Microsys MPX5200
Linux version: 2.6.19
Adeos Patch: Compatible with this Linux
Xenomai version: 2.3.0
 
1.) Is the RT CAN socket deterministic? If I send immediately after
knowing the code is in 4 mS gap interval, how long does the rt socket
send this to the connected device from the time I command rt_dev_send to
the real seding in the Xenomai? Will the Xenomai RT-CAN socket sending
be interrupted by another task or resource? 
 
2.) Are all task application in Xenomai interruptable (or blockable) by
another task or resource irregardless of priority? If this happens....
What is the most time delay it will consume to switch back to my
rt-application task if it is blocked? Lets say I am sending CAN and at
the same time 4 more rt-application are running...
 
3.) Is the highest priority application task can also be blocked by
another process or resource? Will this task yield to another task or
resource if it will be needed? For how long this task switching will
occur so that my application takes control again?
 
4.) Where is rt_timer_read gets its timer value? Is this a predetermined
resolution set in the Xenomai-OS? Is there any relationship of this
timer value in real system pulse?  
 
5.) Is there a way that I can send directly to the RT socket buffer so
that the xenomai can directly send the message without going to the
rt_dev_send on the opened socket? Or is this way impossible and the only
way to send in real-time is through RT CAN socket?
 
6.)  Is an rt application which runs in a periodic task mode will really
executed in periodic intervals? What if the end of the code is not yet
reached and the periodic interval is triggered? Will the task just
continues or will it resign? And then what will happen? Is the periodic
interval will not resign its code when the interval and the code running
overlapped? Will the application code be blocked or will still remain in
running state?
 
7.)  Is there a general protection for a running code that it will be
unblockable for all task and resource for certain lines to be executed?
It is like I will enter to a critical code section and after sending my
CAN message will leave the critical section so that my application will
be able to send immediately and will not be blocked....
 
8.) Why is it that the RT socket CAN of xenomai is still collecting the
incoming frames of an opened socket handle even if it is not requesting
for a read? If the socket will not read, the buffer is becoming full and
will trigger the message buffer full (message discarded). Isn't it that
the xenomai should throw away this frame and free the buffer since the
default timeout will be triggered? The buffer is still being used until
the message overflows when the socket will not read instead of handling
the timeout... It is like as if the CAN device handler will pass the
received CAN message to ALL referenced opened handle eveif it is not
requesting to read the message. Isn't it that if a timeout is already
defined, it should throw away and clear the buffer instead of
continously buffering the "unwanted" frames of the opened socket handle?

 
 
My question might be related or not related to my problem. But I need at
least some of the answers so I can use effectively use the Xenomai task
and have the scheduling in real-time that is accurate to the needed
specification of the project I needed. Please give some recommendation
and comments on things what we might use to address the need of our
real-time project application...
 
Best Regards
 
Urs 
 

[-- Attachment #2: Type: text/html, Size: 14782 bytes --]

Re: [Xenomai-help] General questions

[Sebastian Smolorz]

Urs.Eichholzer wrote:
> Hi all,
>  
> We have some general questions
>  
> Our setup is:
> Hardware MPC5200B on Microsys MPX5200
> Linux version: 2.6.19
> Adeos Patch: Compatible with this Linux
> Xenomai version: 2.3.0
>  
> 1.) Is the RT CAN socket deterministic?

It was wrote with this goal and it uses the service of a real-time 
operating system. So *if* RT-Socket CAN weren't deterministic it would 
be a bug that had to be fixed.

> If I send immediately after
> knowing the code is in 4 mS gap interval, how long does the rt socket
> send this to the connected device from the time I command rt_dev_send to
> the real seding in the Xenomai?

You have to distinguish two cases:
1. The CAN hardware is immediately ready to accept the message that an 
application wants to send. In this case the registers of the hardware 
are filled appropriately and the hardware is instructed to send the CAN 
message. Without waiting for completion of writing the message to the 
CAN bus the rt_dev_send function returns.

2. If the CAN hardware is in the process of sending an message and 
another rt_dev_send call is executed for the same CAN bus rt_dev_send 
blocks as long as the hardware reports that is is ready to accept a new 
message.

> Will the Xenomai RT-CAN socket sending
> be interrupted by another task or resource?

rt_dev_send is executed in the context of the calling task. If it blocks 
(e.g. case 2 above) or if another task with a higer priority wants to 
run the rt_dev_send routine is interrupted.

> 2.) Are all task application in Xenomai interruptable (or blockable) by
> another task or resource irregardless of priority?

Your question covers a bunch of problems ... Generally, Xenomai tasks 
are interruptible. Of course, tasks with higher priorities can interrupt 
tasks with lower ones. All tasks can block on according synchronisation 
objects or during certain system calls. Additionally, real-time 
interrupt handler are executed regardless of any tasks.

> If this happens....
> What is the most time delay it will consume to switch back to my
> rt-application task if it is blocked? Lets say I am sending CAN and at
> the same time 4 more rt-application are running...

There is no general answer for this question. It depends on the 
priorities of the tasks and their work. It is also important what you 
mean with "blocked" e.g. blocked on a Xenomai resource or interrupted by 
the Xenomai scheduler due to a task with a higer priority which is able 
to run.

>  
> 3.) Is the highest priority application task can also be blocked by
> another process or resource?

First, it can block itself e.g. with rt_mutex_acquire if the mutex is 
hold by another task. If you want to block the task from another running 
"context" and it has the highest priority then it is only possible when 
this task is already blocked or interrupted e.g. by an real-time 
interrupt handler.

> Will this task yield to another task or
> resource if it will be needed? For how long this task switching will
> occur so that my application takes control again?

Again, this depends on many things.

> 4.) Where is rt_timer_read gets its timer value? Is this a predetermined
> resolution set in the Xenomai-OS? Is there any relationship of this
> timer value in real system pulse?

As the documentation states (for 2.3) rt_timer_read returns the time 
either in nanoseconds or in local CPU ticks. The conversion between them 
can be done with rt_timer_ticks2ns() and rt_timer_ns2ticks(). I don't 
know the timer source of your special board but I can imagine that a 
dedicated hardware timer is used for this.

> 5.) Is there a way that I can send directly to the RT socket buffer so
> that the xenomai can directly send the message without going to the
> rt_dev_send on the opened socket? Or is this way impossible and the only
> way to send in real-time is through RT CAN socket?

Why do you want to do this? This is really a bad idea. And for this 
reason there is no provided way.

> 6.)  Is an rt application which runs in a periodic task mode will really
> executed in periodic intervals? What if the end of the code is not yet
> reached and the periodic interval is triggered? Will the task just
> continues or will it resign?
> And then what will happen? Is the periodic
> interval will not resign its code when the interval and the code running
> overlapped? Will the application code be blocked or will still remain in
> running state?

If you use the rt_task_wait_period() function all answers can be find in 
the API documentation:
http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__task.html#g1645d3a072ef3cefeed3bcbb27dcf108

>  
> 7.)  Is there a general protection for a running code that it will be
> unblockable for all task and resource for certain lines to be executed?
> It is like I will enter to a critical code section and after sending my
> CAN message will leave the critical section so that my application will
> be able to send immediately and will not be blocked....

Normally, user applications should not need to block the whole system in 
  such a way i.e. including other tasks and interrupts. A critical 
section usually is critical in respect of data shared between several 
tasks. For this case there are synchronisation methods like mutexes and 
semaphores. A careful designed application structure including the 
allocation of task priorities is also important.

> 8.) Why is it that the RT socket CAN of xenomai is still collecting the
> incoming frames of an opened socket handle even if it is not requesting
> for a read? If the socket will not read, the buffer is becoming full and
> will trigger the message buffer full (message discarded). Isn't it that
> the xenomai should throw away this frame and free the buffer since the
> default timeout will be triggered? The buffer is still being used until
> the message overflows when the socket will not read instead of handling
> the timeout... It is like as if the CAN device handler will pass the
> received CAN message to ALL referenced opened handle eveif it is not
> requesting to read the message. Isn't it that if a timeout is already
> defined, it should throw away and clear the buffer instead of
> continously buffering the "unwanted" frames of the opened socket handle?

So you only want to get CAN messages when an application is in the 
process of executing rt_dev_recv? Can you control that when the task is 
between two rt_dev_recv calls no message will arrive? You can't. 
Therefore the driver receives all messages and copies them to those 
sockets which have an interest in them. You can set a filter for each 
socket which messages are to be received with rt_dev_setsockopt. Please 
see the CAN device profile for more details:
http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__rtcan.html

Probably you didn't set any filter in your application which means that 
your sockets receive all messages. Without any rt_dev_recv call it is 
clear that your socket buffer will be full eventually.

-- 
Sebastian

Re: [Xenomai-help] General questions

[Sebastian Smolorz]

Sebastian Smolorz wrote:
> You have to distinguish two cases:
> 1. The CAN hardware is immediately ready to accept the message that an 
> application wants to send. In this case the registers of the hardware 
> are filled appropriately and the hardware is instructed to send the CAN 
> message. Without waiting for completion of writing the message to the 
> CAN bus the rt_dev_send function returns.
> 
> 2. If the CAN hardware is in the process of sending an message and 
> another rt_dev_send call is executed for the same CAN bus rt_dev_send 
> blocks as long as the hardware reports that is is ready to accept a new 
> message.
To be correct, replace "as long as" with "until".

-- 
Sebastian

Re: [Xenomai-help] General questions

[Wolfgang Grandegger]

Hi Urs,

Urs.Eichholzer wrote:
> Hi all,
> 
>  
> 
> We have some general questions
> 
>  
> 
> Our setup is:
> 
> Hardware MPC5200B on Microsys MPX5200
> 
> Linux version: 2.6.19
> 
> Adeos Patch: Compatible with this Linux
> 
> Xenomai version: 2.3.0

You should definitely update to 2.3.5 to benefit from bug fixes
accumulated over 1.5 years.

> 1.) Is the RT CAN socket deterministic? If I send immediately after
> knowing the code is in 4 mS gap interval, how long does the rt socket
> send this to the connected device from the time I command rt_dev_send to
> the real seding in the Xenomai? Will the Xenomai RT-CAN socket sending
> be interrupted by another task or resource?

RT-Socket-CAN is a real-time capable, deterministic CAN protocol stack.
The sending task might be interrupted by a higher priority task or an
interrupt handler. If more than one task is sending CAN messages to the
same device, the send call might block if a send is in progress, because
out-going messages are not queued for the sake of latency. How long the
sending tasks blocks depends on other task running at higher priority.

> 2.) Are all task application in Xenomai interruptable (or blockable) by
> another task or resource irregardless of priority? If this happens....

A task might be interrupted by a higher priority task or an interrupt
handler. Interrupt and exception handling is always handled first and
therefore the ISR should be small, which is usually the case.

> What is the most time delay it will consume to switch back to my
> rt-application task if it is blocked? Lets say I am sending CAN and at
> the same time 4 more rt-application are running...

As said, it depends on the task running at higher priority. The pure
context switch is in the order of tenth of micro-seconds for your
processor, I would guess.

> 3.) Is the highest priority application task can also be blocked by
> another process or resource? Will this task yield to another task or
> resource if it will be needed? For how long this task switching will
> occur so that my application takes control again?

The highest priority task can only be interrupted by interrupt handling,
which usually does not take that long. I would guess less than 10..20
micro-seconds.

> 4.) Where is rt_timer_read gets its timer value? Is this a predetermined
> resolution set in the Xenomai-OS? Is there any relationship of this
> timer value in real system pulse? 

The timer implementation is hardware dependent. On your system, a
one-shot timer based on the PowerPC decrementer is used. It runs at a
defined frequency. See also:
http://www.go-ecs.com/ppc/ppctek1.htm#DTB



> 5.) Is there a way that I can send directly to the RT socket buffer so
> that the xenomai can directly send the message without going to the
> rt_dev_send on the opened socket? Or is this way impossible and the only
> way to send in real-time is through RT CAN socket?

You could access the CAN hardware directly but you need an RTDM driver
to do it from user space. But I do not see a need to do that?
RT-Socket-CAN should do what you need, I think.

> 6.)  Is an rt application which runs in a periodic task mode will really
> executed in periodic intervals? What if the end of the code is not yet
> reached and the periodic interval is triggered? Will the task just
> continues or will it resign? And then what will happen? Is the periodic
> interval will not resign its code when the interval and the code running
> overlapped? Will the application code be blocked or will still remain in
> running state?

If the task overruns the period, it wakes up as soon as the wait
function is called. For further information see:

http://www.xenomai.org/documentation/trunk/html/api/index.html

> 7.)  Is there a general protection for a running code that it will be
> unblockable for all task and resource for certain lines to be executed?

Yes, e.g.:

http://www.xenomai.org/documentation/trunk/html/api/index.html

But disabling interrupts globally in user space is not possible.

> It is like I will enter to a critical code section and after sending my
> CAN message will leave the critical section so that my application will
> be able to send immediately and will not be blocked....

You do not need that to send out CAN messages. The task priority should
be enough.

> 8.) Why is it that the RT socket CAN of xenomai is still collecting the
> incoming frames of an opened socket handle even if it is not requesting
> for a read? If the socket will not read, the buffer is becoming full and
> will trigger the message buffer full (message discarded). Isn't it that
> the xenomai should throw away this frame and free the buffer since the
> default timeout will be triggered? The buffer is still being used until
> the message overflows when the socket will not read instead of handling
> the timeout... It is like as if the CAN device handler will pass the
> received CAN message to ALL referenced opened handle eveif it is not
> requesting to read the message. Isn't it that if a timeout is already
> defined, it should throw away and clear the buffer instead of
> continously buffering the "unwanted" frames of the opened socket handle?

If you bind a socket it will receive incoming messages and queue them in
a buffer by default, which might overrun if there is no task reading
them out. If you do not want to receive messages on a socket, either use
sendto without binding the socket as shown here:

http://www.rts.uni-hannover.de/xenomai/lxr/source/src/utils/can/rtcansend.c#089

or disable reception of messages on a bound socket as shown here:

http://www.rts.uni-hannover.de/xenomai/lxr/source/src/utils/can/rtcansend.c#252

The debug message can be disabled by unsetting the kernel configuration
option CONFIG_XENO_DRIVERS_CAN_DEBUG:

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/Kconfig#009

Then the buffer overflows will silently be ignored. A counter RX_BufFull
is always incremented, which can be listed with "# cat
/proc/rtcan/sockets" as shown here:

http://www.rts.uni-hannover.de/xenomai/lxr/source/src/utils/can/README#117

> My question might be related or not related to my problem. But I need at
> least some of the answers so I can use effectively use the Xenomai task
> and have the scheduling in real-time that is accurate to the needed
> specification of the project I needed. Please give some recommendation
> and comments on things what we might use to address the need of our
> real-time project application...

What is your real problem? You seem to loose determinism somehow. This
can happen, when a real-time task blocks on a standard Linux system call
like write, read, printf, etc. Then the task switches to secondary mode
and determinism is lost. You can trigger a signal when that happens as
shown here:

http://www.xenomai.org/documentation/trunk/html/api/sigxcpu_8c-example.html

Concerning latencies. For a similar system I have measure a max. latency
of 120 us to acknowledge an external interrupt in a Xenomai user space
application. See also:

http://www.denx.de/wiki/DULG/AN2008_03_Xenomai_gpioirqbench

Wolfgang.

Re: [Xenomai-help] General questions

[Philippe Gerum]

Urs.Eichholzer wrote:
> Hi all,
> 
>  
> 
> We have some general questions
> 
>  
> 
> Our setup is:
> 
> Hardware MPC5200B on Microsys MPX5200
> 
> Linux version: 2.6.19
> 
> Adeos Patch: Compatible with this Linux
> 
> Xenomai version: 2.3.0
> 

Actually, you could use any later Xenomai 2.x version with that patch. I would
suggest to go for 2.4.3 for now, and upgrade to the upcoming 2.4.4 maintenance 
release when it is out, along with Adeos 2.6.19-ppc-1.5-02.

--
Philippe