* Re: [Xenomai-help] General questions
2008-05-28 2:43 [Xenomai-help] General questions Urs.Eichholzer
@ 2008-05-28 8:26 ` Sebastian Smolorz
2008-05-28 8:34 ` Sebastian Smolorz
2008-05-28 8:45 ` Wolfgang Grandegger
2008-05-29 16:50 ` Philippe Gerum
2 siblings, 1 reply; 5+ messages in thread
From: Sebastian Smolorz @ 2008-05-28 8:26 UTC (permalink / raw)
To: Urs.Eichholzer; +Cc: xenomai
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] General questions
2008-05-28 2:43 [Xenomai-help] General questions Urs.Eichholzer
2008-05-28 8:26 ` Sebastian Smolorz
@ 2008-05-28 8:45 ` Wolfgang Grandegger
2008-05-29 16:50 ` Philippe Gerum
2 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Grandegger @ 2008-05-28 8:45 UTC (permalink / raw)
To: Urs.Eichholzer; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 5+ messages in thread