Re: [Xenomai] Xenomai Digest, Vol 11, Issue 55

Re: [Xenomai] Xenomai Digest, Vol 11, Issue 55

[吴剑锋]

Hi

Somebody can help me how to use the rt_alarm function in xenomai native skin to make watchdog function ?

For example , we want to monitor a task and this task is use for a lot of calculation . Every calculation time is 50 ms ,so we want to check the calculation time at every Period . if the timer is longer than 50 ms, the calculation task should be forced to suspend and sent to a error signal.

So, we don’t know how to do it ?what’s meaning the “ALARM_VALUE ,ALARM_INTERVAL “ in the “usr_alarm.c” sample file ? How to setting ? maybe is there some codes to solve our issue ?



thanks very much!


nick




At 2013-03-29 19:00:01,xenomai-request@xenomai.org wrote:
>Send Xenomai mailing list submissions to
>	xenomai@xenomai.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://www.xenomai.org/mailman/listinfo/xenomai
>or, via email, send a message with subject or body 'help' to
>	xenomai-request@xenomai.org
>
>You can reach the person managing the list at
>	xenomai-owner@xenomai.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xenomai digest..."
>
>
>Today's Topics:
>
>   1. Re: Decrease Latency (below 10 us) on x32 or x32_64?
>      (Gilles Chanteperdrix)
>   2. Re: Decrease Latency (below 10 us) on x32 or x32_64?
>      (Manuel Huber)
>   3. Re: Decrease Latency (below 10 us) on x32 or x32_64?
>      (Gilles Chanteperdrix)
>   4. patch to src/utils/can/rtcansend.c to support data from a
>      file (Daniel M. Drucker, Ph.D.)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 28 Mar 2013 13:46:05 +0100
>From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>To: Manuel Huber <manuel.h87@gmail.com>
>Cc: xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
>	x32_64?
>Message-ID: <51543B8D.3000301@xenomai.org>
>Content-Type: text/plain; charset=UTF-8
>
>On 03/28/2013 11:06 AM, Manuel Huber wrote:
>
>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>
>>>> Hello!
>>>>
>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>> option for some minutes and afterwards captured the variables in
>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>> any difference.
>>>>
>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>> the trace, if you have time for it...
>>>
>>> The traces are too short. Try:
>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>
>>> There should be at least a "tick@" trace indicating the time when the
>>> timer was supposed to tick and when it did not, so that we have an idea
>>> of the latency.
>>>
>>> What is the period you use for the latency test?
>>>
>> Hello!
>> 
>> Sorry, I have run the same tests again, just with back_trace_points
>> set to 1000. I've run the latency tool for 5 minutes with a period of
>> 100 us (default).
>
>
>Well, there is only one strange spot:
>:|  # func                 -31	  0.324  ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>:|  # func                 -31+   8.732  lapic_next_event+0x3 (ipipe_timer_set+0x77)
>:|  # func                 -22+   3.484  __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>:|  # func                 -19+   5.443  __xnlock_spin+0x9 (T.1349+0x55)
>:|  # [ 1996] Xorg    -1   -13	  0.211  __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>
>Which would indicate that maybe the bus is busy with another core.
>But strangely the latency is around 36us as measure with the other traces.
>>From your traces, I do not see anything pathological.
>
>> 
>> I don't think it's related, but xeno-test fails on the machine, and I
>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>> with a factor of 6 (as described here:
>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>
>
>And the error message is...?
>
>-- 
>                                                                Gilles.
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 28 Mar 2013 14:04:25 +0100
>From: Manuel Huber <manuel.h87@gmail.com>
>To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>,
>	xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
>	x32_64?
>Message-ID: <51543FD9.6080707@gmail.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>On 2013-03-28 13:46, Gilles Chanteperdrix wrote:
>> On 03/28/2013 11:06 AM, Manuel Huber wrote:
>>
>>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>>> option for some minutes and afterwards captured the variables in
>>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>>> any difference.
>>>>>
>>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>>> the trace, if you have time for it...
>>>> The traces are too short. Try:
>>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>>
>>>> There should be at least a "tick@" trace indicating the time when the
>>>> timer was supposed to tick and when it did not, so that we have an idea
>>>> of the latency.
>>>>
>>>> What is the period you use for the latency test?
>>>>
>>> Hello!
>>>
>>> Sorry, I have run the same tests again, just with back_trace_points
>>> set to 1000. I've run the latency tool for 5 minutes with a period of
>>> 100 us (default).
>>
>> Well, there is only one strange spot:
>> :|  # func                 -31	  0.324  ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>> :|  # func                 -31+   8.732  lapic_next_event+0x3 (ipipe_timer_set+0x77)
>> :|  # func                 -22+   3.484  __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>> :|  # func                 -19+   5.443  __xnlock_spin+0x9 (T.1349+0x55)
>> :|  # [ 1996] Xorg    -1   -13	  0.211  __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>>
>> Which would indicate that maybe the bus is busy with another core.
>> But strangely the latency is around 36us as measure with the other traces.
>>  From your traces, I do not see anything pathological.
>>
>>> I don't think it's related, but xeno-test fails on the machine, and I
>>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>>> with a factor of 6 (as described here:
>>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>>
>> And the error message is...?
>>
>Hello!
>
>>  From your traces, I do not see anything pathological.
>Would you expect the timing to be better with a 64bit-Kernel? Could
>it be related to memory management overhead of the Kernel...
>
>> And the error message is...?
>Oh, sorry; The message was:
>ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>I multiplied CONFIG_XENO_OPT_SYS_HEAPSZ and CONFIG_XENO_OPT_SYS_STACKPOOLSZ
>each by a factor of 6. The resulting values are:
>CONFIG_XENO_OPT_SYS_HEAPSZ = 1536
>CONFIG_XENO_OPT_SYS_STACKPOOLSZ = 768
>
>I got the info from an old posting you wrote and it fixed the
>problem as expected.
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Thu, 28 Mar 2013 21:24:34 +0100
>From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>To: Manuel Huber <manuel.h87@gmail.com>
>Cc: xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
>	x32_64?
>Message-ID: <5154A702.8060307@xenomai.org>
>Content-Type: text/plain; charset=UTF-8
>
>On 03/28/2013 02:04 PM, Manuel Huber wrote:
>
>> On 2013-03-28 13:46, Gilles Chanteperdrix wrote:
>>> On 03/28/2013 11:06 AM, Manuel Huber wrote:
>>>
>>>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>>>> option for some minutes and afterwards captured the variables in
>>>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>>>> any difference.
>>>>>>
>>>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>>>> the trace, if you have time for it...
>>>>> The traces are too short. Try:
>>>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>>>
>>>>> There should be at least a "tick@" trace indicating the time when the
>>>>> timer was supposed to tick and when it did not, so that we have an idea
>>>>> of the latency.
>>>>>
>>>>> What is the period you use for the latency test?
>>>>>
>>>> Hello!
>>>>
>>>> Sorry, I have run the same tests again, just with back_trace_points
>>>> set to 1000. I've run the latency tool for 5 minutes with a period of
>>>> 100 us (default).
>>>
>>> Well, there is only one strange spot:
>>> :|  # func                 -31	  0.324  ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>>> :|  # func                 -31+   8.732  lapic_next_event+0x3 (ipipe_timer_set+0x77)
>>> :|  # func                 -22+   3.484  __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>>> :|  # func                 -19+   5.443  __xnlock_spin+0x9 (T.1349+0x55)
>>> :|  # [ 1996] Xorg    -1   -13	  0.211  __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>>>
>>> Which would indicate that maybe the bus is busy with another core.
>>> But strangely the latency is around 36us as measure with the other traces.
>>>  From your traces, I do not see anything pathological.
>>>
>>>> I don't think it's related, but xeno-test fails on the machine, and I
>>>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>>>> with a factor of 6 (as described here:
>>>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>>>
>>> And the error message is...?
>>>
>> Hello!
>> 
>>>  From your traces, I do not see anything pathological.
>> Would you expect the timing to be better with a 64bit-Kernel? Could
>> it be related to memory management overhead of the Kernel...
>
>
>You would probably have better latencies with using Xenomai on only one 
>core. But 36us with the tracer on does not look so bad, does it?
>
>Did you try the configuration options I gave in the answer to your 
>first mail?
>
>> 
>>> And the error message is...?
>> Oh, sorry; The message was:
>> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>> I multiplied CONFIG_XENO_OPT_SYS_HEAPSZ and CONFIG_XENO_OPT_SYS_STACKPOOLSZ
>> each by a factor of 6. The resulting values are:
>> CONFIG_XENO_OPT_SYS_HEAPSZ = 1536
>> CONFIG_XENO_OPT_SYS_STACKPOOLSZ = 768
>> 
>> I got the info from an old posting you wrote and it fixed the
>> problem as expected.
>
>
>This is also documented in the TROUBLESHOOTING guide:
>http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_switchtest_fails_with_pthread_create_resource_temporarily_unavailable
>
>-- 
>                                                                Gilles.
>
>
>
>------------------------------
>
>Message: 4
>Date: Thu, 28 Mar 2013 18:00:53 -0400
>From: "Daniel M. Drucker, Ph.D." <dmd@interactive-motion.com>
>To: xenomai@xenomai.org
>Subject: [Xenomai] patch to src/utils/can/rtcansend.c to support data
>	from a	file
>Message-ID:
>	<CAD1EtognG+9J_Bbo3x6AsBCJ4eU4SLrXQz=wDvJtFw0vCSZ8NQ@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>When sending a large number of CAN messages from a script (in our case, to
>initialize a servo), rtcansend can be somewhat slow because every message
>requires a setup and teardown.
>
>I added a --file flag to rtcansend which allows you to instead read bytes
>from a file (or stdin, using '-' as the filename). The file has one CAN
>message per line, in the same format (space-separated) as it would have
>been in the can-msg on the command line. Blank lines are ignored. Lines
>which start with a ' ' (space) or '#' (hash) character are ignored. If a
>filename is given, any can-msg specified on the command line is ignored.
>
>I hope this of use to someone, and it'd be really great if this could be
>merged!
>
>Thanks,
>Daniel
>
>https://gist.github.com/dmd/5267158 and inlined here:
>
>--- xenomai-2.6.2.1/src/utils/can/rtcansend.c 2013-01-22 14:37:05.000000000
>-0500
>+++ robot4/crob/rtcansendmulti.c 2013-03-28 17:47:21.436106822 -0400
>@@ -1,4 +1,5 @@
> #include <stdio.h>
>+#include <string.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <unistd.h>
>@@ -18,9 +19,10 @@
> static void print_usage(char *prg)
> {
>     fprintf(stderr,
>-    "Usage: %s <can-interface> [Options] <can-msg>\n"
>+    "Usage: %s <can-interface> [Options] [<can-msg>]\n"
>     "<can-msg> can consist of up to 8 bytes given as a space separated
>list\n"
>     "Options:\n"
>+    " -f, --file=FILENAME   file to read bytes from instead of the command
>line. one list per line.\n"
>     " -i, --identifier=ID   CAN Identifier (default = 1)\n"
>     " -r  --rtr             send remote request\n"
>     " -e  --extended        send extended frame\n"
>@@ -45,7 +47,7 @@
> static nanosecs_rel_t timeout = 0;
> static struct can_frame frame;
> static struct sockaddr_can to_addr;
>-
>+const char* input_filename = NULL;
>
> void cleanup(void)
> {
>@@ -127,6 +129,7 @@
>
>     struct option long_options[] = {
>  { "help", no_argument, 0, 'h' },
>+ { "file", required_argument, NULL, 'f'},
>  { "identifier", required_argument, 0, 'i'},
>  { "rtr", no_argument, 0, 'r'},
>  { "extended", no_argument, 0, 'e'},
>@@ -148,15 +151,20 @@
>
>     frame.can_id = 1;
>
>-    while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:",
>+    while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:f:",
>       long_options, NULL)) != -1) {
>  switch (opt) {
>  case 'h':
>     print_usage(argv[0]);
>     exit(0);
>
>+ case 'f':
>+    input_filename = optarg;
>+    break;
>+
>  case 'p':
>     print = strtoul(optarg, NULL, 0);
>+    /* fall through */
>
>  case 'v':
>     verbose = 1;
>@@ -263,18 +271,6 @@
>  }
>     }
>
>-    if (count)
>- frame.can_dlc = sizeof(int);
>-    else {
>- for (i = optind + 1; i < argc; i++) {
>-    frame.data[dlc] = strtoul(argv[i], NULL, 0);
>-    dlc++;
>-    if( dlc == 8 )
>- break;
>- }
>- frame.can_dlc = dlc;
>-    }
>-
>     if (rtr)
>  frame.can_id |= CAN_RTR_FLAG;
>
>@@ -298,7 +294,49 @@
>  goto failure;
>     }
>
>-    rt_task();
>+    if (input_filename != NULL) {
>+ if (!strcmp(input_filename, "-"))
>+    input_filename = "/dev/stdin";
>+
>+ FILE *file = fopen(input_filename, "r");
>+
>+ if (file != NULL) {
>+    char line [1024];
>+    while (fgets(line, sizeof line, file) != NULL) {
>+ // put the data into frame
>+ char * pch;
>+ if (line[0] == '#' || line[0] == ' ' || line[0] == '\n') continue;
>+ pch = strtok(line, " ");
>+ dlc = 0;
>+ while ((pch != NULL) && (dlc < 8)) {
>+    frame.data[dlc] = strtoul(pch, NULL, 0);
>+    pch = strtok(NULL, " ");
>+    dlc++;
>+ }
>+ frame.can_dlc = dlc;
>+ rt_task();
>+    }
>+    fclose(file);
>+ }
>+ else {
>+    perror(input_filename);
>+    goto failure;
>+ }
>+    }
>+    else {
>+ if (count)
>+    frame.can_dlc = sizeof(int);
>+ else {
>+    for (i = optind + 1; i < argc; i++) {
>+ frame.data[dlc] = strtoul(argv[i], NULL, 0);
>+ dlc++;
>+ if( dlc == 8 )
>+    break;
>+    }
>+    frame.can_dlc = dlc;
>+ }
>+ rt_task();
>+    }
>
>     cleanup();
>     return 0;
>
>
>------------------------------
>
>_______________________________________________
>Xenomai mailing list
>Xenomai@xenomai.org
>http://www.xenomai.org/mailman/listinfo/xenomai
>
>
>End of Xenomai Digest, Vol 11, Issue 55
>***************************************

Re: [Xenomai] Xenomai Digest, Vol 11, Issue 55

[Gilles Chanteperdrix]

On 04/01/2013 02:54 PM, 吴剑锋 wrote:

> 
> 
> 
> Hi
> 
> Somebody can help me how to use the rt_alarm function in xenomai
> native skin to make watchdog function ?
> 


Hi,

it would be nice if your post dit not ignore so much the netiquette.
Your mail does not have a valid subject, it has lines longer than 80
characters, and it is posted on top of tens of lines concerning
unrelated subjects.

Besides, the rt_alarm functions are documented in xenomai's doxygen
documentation, please read that documentation and come back with precise
questions about the parts of the documentation which you do not understand.

Regards.


-- 
                                                                Gilles.