Re: [Xenomai-help] libnative and libxenomai dependy problem
On 04/23/2012 03:57 AM, Willy Lambert wrote: > 2012/4/23 Gilles Chanteperdrix : >> On 04/23/2012 01:57 AM, Willy Lambert wrote: >>> Hi, >>> >>> I just run into the same kind of problem of a one year old discussion : >>> http://www.mail-archive.com/xenomai-help@gna.org/msg12669.html >>> >>> having such kind of errors : >>> /usr/lib/libnative.so.3: undefined symbol: xeno_current_mode_key >>> I have a xenomai 2.6.0 recompiled from sources with the --dl-open >>> option enabled. >>> root@beta(10.0):~# cat /proc/xenomai/version >>> 2.6.0 >>> >>> >>> I re-post something because I'm not sure it is up to date and as I >>> have the next version I am suprised the problem still arises >>> >>> I have 2 question : >>> _ did I missconfigured something in my compiller flags or linking ? >>> _ are the solutions of last thread still up to date ? >>> >> >> You need to dlopen libxenomai in order for dlopen(libnative) to succeed. >> >> -- >>Gilles. > > In fact I never called dlopen(libnative) myself. It is done in a > library to which I am linked. Do I have a to dlopen it in my personnal > code ? > you have to manage for dlopen(libxenomai) to be called before dlopen(libnative), and with the RTDL_GLOBAL flag so that libnative will find the symbols defined by libxenomai. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote:
> Hi,
>
> I have a message in dmesg about SMI workaround :
> Xenomai: SMI-enabled chipset found, but SMI workaround disabled
> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter
> high interrupt latencies!
>
> My kernel should be configured properly and following the "In case of
> high latencies" of
> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did
> some tests.
>
> Latency test is here (if it is us it should be ok no ?):
>
> RTT| 00:00:22 (periodic user-mode task, 100 us period, priority 99)
> RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat
> worst
> RTD| 1.238| 1.365| 4.778| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.388| 5.292| 0| 0| 0.605|
> 9.414
> RTD| 0.847| 1.365| 6.113| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.363| 4.676| 0| 0| 0.605|
> 9.414
> RTD| 1.229| 1.365| 4.489| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.368| 4.194| 0| 0| 0.605|
> 9.414
> RTD| 1.231| 1.386| 5.625| 0| 0| 0.605|
> 9.414
> RTD| 0.681| 1.365| 6.020| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.365| 4.762| 0| 0| 0.605|
> 9.414
> RTD| 1.165| 1.366| 6.987| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.364| 5.453| 0| 0| 0.605|
> 9.414
> RTD| 1.093| 1.382| 5.567| 0| 0| 0.605|
> 9.414
> RTD| 0.629| 1.365| 6.437| 0| 0| 0.605|
> 9.414
> RTD| 1.236| 1.364| 4.584| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.366| 6.671| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.372| 4.436| 0| 0| 0.605|
> 9.414
> RTD| 0.981| 1.384| 5.949| 0| 0| 0.605|
> 9.414
> RTD| 0.626| 1.363| 5.844| 0| 0| 0.605|
> 9.414
> RTD| 1.217| 1.364| 4.448| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.365| 4.451| 0| 0| 0.605|
> 9.414
> RTD| 1.236| 1.368| 4.619| 0| 0| 0.605|
> 9.414
>
> So I did a lspci -nn | grep LPC which gives :
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC
> Interface Controller [8086:2815] (rev 04)
>
> It is adviced to edit the ksrc/arch/x86/smi.c file. Is it still up to
> date ? If yes could you help me to edit it ? I suppose it is this
> section :
> static struct pci_device_id rthal_smi_pci_tbl[] = {
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_10)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801E_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_5)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PCH_LPC_MIN+7)},
> {0,},
> };
>
> I suppose I should add a line, with something from : pci_ids.h, but
> it's not very clear to me which one to select.
If you see the messages, the ids for your chipset already are in the
table. If you want to enabled the SMI workaround, simply enable it in
the kernel configuration.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the "In case of high latencies" of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Adeos patch for x86_64
Greetings, I have some confusion - The Adeos patches support x86 architecture. They haven't mentioned anything explicitly about x86_64 architecture. Can I assume that these x86 patches of Adeos (with Xenomai) will run properly on a 64 bit machine? http://download.gna.org/adeos/patches/v2.6/ -Anisha ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
2012/4/23 Philippe Gerum : > On 04/23/2012 03:51 AM, Willy Lambert wrote: >> >> Hi, >> >> I have a message in dmesg about SMI workaround : >> Xenomai: SMI-enabled chipset found, but SMI workaround disabled >> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter >> high interrupt latencies! >> >> My kernel should be configured properly and following the "In case of >> high latencies" of >> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did >> some tests. >> >> Latency test is here (if it is us it should be ok no ?): >> > > Yes, this looks ok, but you need to run this test longer, and try a few > usual suspects like plugging in/out USB devices while doing so (e.g. mouse, > netdev). > > The point of this message is to tell you that your chipset is known to > create latency issues in some cases (like most Intel chipset these days), > but you did not enable the Xenomai code which works around such issues by > shutting down problematic SMI sources. That may be right, or even required > to leave all the SMI sources enabled (e.g. thermal control), but this might > also lead to unacceptable latency spots. YMMV. > > This is basically a heads up message. > > -- > Philippe. Ok, thanks for answers. I did the test again , playing with usb and using the stress program to generate CPU load. The max latency for now is 15us in 4 mins. So I think it will be ok to keep SMI on for the time. Please let me know if this test is still stoo short. ^C---|---|---|---||--|- RTS| 0.604| 2.332| 15.161| 0| 0|00:03:59/00:03:59 Do you know by chance where I can found infos about SMI sources ? I suppose it is not in the ICH8M docs, it would be in my board doc ? Or have I a soft way to do this check so that I don't have to spend time with my vendor which will obviously have hard time to answer that ? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
2012/4/23 Willy Lambert : > 2012/4/23 Philippe Gerum : >> On 04/23/2012 03:51 AM, Willy Lambert wrote: >>> >>> Hi, >>> >>> I have a message in dmesg about SMI workaround : >>> Xenomai: SMI-enabled chipset found, but SMI workaround disabled >>> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter >>> high interrupt latencies! >>> >>> My kernel should be configured properly and following the "In case of >>> high latencies" of >>> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did >>> some tests. >>> >>> Latency test is here (if it is us it should be ok no ?): >>> >> >> Yes, this looks ok, but you need to run this test longer, and try a few >> usual suspects like plugging in/out USB devices while doing so (e.g. mouse, >> netdev). >> >> The point of this message is to tell you that your chipset is known to >> create latency issues in some cases (like most Intel chipset these days), >> but you did not enable the Xenomai code which works around such issues by >> shutting down problematic SMI sources. That may be right, or even required >> to leave all the SMI sources enabled (e.g. thermal control), but this might >> also lead to unacceptable latency spots. YMMV. >> >> This is basically a heads up message. >> >> -- >> Philippe. > > Ok, thanks for answers. > > I did the test again , playing with usb and using the stress program > to generate CPU load. The max latency for now is 15us in 4 mins. So I > think it will be ok to keep SMI on for the time. Please let me know if > this test is still stoo short. > ^C---|---|---|---||--|- > RTS| 0.604| 2.332| 15.161| 0| 0| 00:03:59/00:03:59 > > Do you know by chance where I can found infos about SMI sources ? I > suppose it is not in the ICH8M docs, it would be in my board doc ? Or > have I a soft way to do this check so that I don't have to spend time > with my vendor which will obviously have hard time to answer that ? Btw is there any way to test latencies without xenomai (or in secondary mode) to compare ? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 01:05 PM, Willy Lambert wrote: > 2012/4/23 Philippe Gerum : >> On 04/23/2012 03:51 AM, Willy Lambert wrote: >>> >>> Hi, >>> >>> I have a message in dmesg about SMI workaround : >>> Xenomai: SMI-enabled chipset found, but SMI workaround disabled >>> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter >>> high interrupt latencies! >>> >>> My kernel should be configured properly and following the "In case of >>> high latencies" of >>> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did >>> some tests. >>> >>> Latency test is here (if it is us it should be ok no ?): >>> >> >> Yes, this looks ok, but you need to run this test longer, and try a few >> usual suspects like plugging in/out USB devices while doing so (e.g. mouse, >> netdev). >> >> The point of this message is to tell you that your chipset is known to >> create latency issues in some cases (like most Intel chipset these days), >> but you did not enable the Xenomai code which works around such issues by >> shutting down problematic SMI sources. That may be right, or even required >> to leave all the SMI sources enabled (e.g. thermal control), but this might >> also lead to unacceptable latency spots. YMMV. >> >> This is basically a heads up message. >> >> -- >> Philippe. > > Ok, thanks for answers. > > I did the test again , playing with usb and using the stress program > to generate CPU load. The max latency for now is 15us in 4 mins. So I > think it will be ok to keep SMI on for the time. Please let me know if > this test is still stoo short. > ^C---|---|---|---||--|- > RTS| 0.604| 2.332| 15.161| 0| 0|00:03:59/00:03:59 > > Do you know by chance where I can found infos about SMI sources ? I > suppose it is not in the ICH8M docs, it would be in my board doc ? Or > have I a soft way to do this check so that I don't have to spend time > with my vendor which will obviously have hard time to answer that ? The list of potential SMI sources IS in the ICH8M docs. Whether these sources are used by your board essentially depends on the BIOS implementation (an SMI traps into BIOS code). So the theoretical answer to this question is to disassemble the the BIOS blob. The practical answer is to run latency during a few hours, under stress using all the hardware which will be used in your target project (network card, disk I/Os, USB key I/Os, etc...). If an SMI is used but latencies remain acceptable with regard to your goals, no reason to bother. If you find unacceptable latencies, see the TROUBLESHOOTING guide, to see how to enable SMI workaround. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
Hi Folks,
Following my tests with PWM generation using GPIO in user space [1],
I've made the RTDM module [2] to further reduce the jitter. As a
result, jitter was improved, but still under heavy system load the
servo motor I am trying to control starts shaking. Now, I fill stuck
and hope to get some help here.
At one hand, I can not imaging that 800MHz ARM (BeagleBoard xM) could
not manage to generate 20mS PWMs from RTDM driver precise enough to
avoid sporadic servo movements. So probably I am doing something
wrong. On the other hand, I do not see where the possible mistake can
happen and hope that someone experienced in with Xenomai could help.
There is an article about observed behavior [3] with more details, but
the core problem, I guess, boils down to the following code fragment:
void pwm_task_proc(void *arg) {
const int which = (int)arg;
// Toggling GPIO pin
for(;;) {
//set_data_out has offset 0x94 . Set gpio pin to 1 (up)
iowrite32(0x4000, gpio + 0x6094);
// wait requested pulse width time (duty)
if(0 != rtdm_task_sleep(up_period[which]))
rtdm_printk("PWM: rtdm_task_sleep() returns error\n");
//clear_data_out has offset 0x90 . Set gpio pin to 0 (down)
iowrite32(0x4000, gpio + 0x6090);
// wait until the next pulse should start (20mS interval)
if(0 != rtdm_task_wait_period())
rtdm_printk("PWM: rtdm_task_wait_period() returns error\n");
}
This is the function running as a periodic task started with the following call:
retval = rtdm_task_init(&pwm_task[i], // there is currently only one
element in this array
"pwm-task",
pwm_task_proc,
0,
RTDM_TASK_HIGHEST_PRIORITY,
2000); // 20ms period
It works fine until I put the system under about 95% load (just by
running tar jcf f.tbz2 /usr/lib). After that, the jitter of the
generated PWMs increasing to the level where it is not only observable
on the scope (as presented in [3]) but also servo motor starts
shaking, so it is clearly visible even without any measurements.
Honesly, I am failing to see any ways to improve this code. It is
already running in the kernel space and there are only memory writes
and RTDM wati functions involved. So I am wondering whether I hit the
limit of what is possible with Xenomai+Linux? I hope I am not and
would highly appreciate any hints or suggestions.
Thank you,
Andrey.
[1]
http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
[2] https://github.com/andreynech/rtdm-pwm
[3]
http://veter-project.blogspot.com/2012/04/precise-pwms-with-gpio-using-xenomai.html
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 01:56 PM, Andrey Nechypurenko wrote:
> Hi Folks,
>
> Following my tests with PWM generation using GPIO in user space [1],
> I've made the RTDM module [2] to further reduce the jitter. As a
> result, jitter was improved, but still under heavy system load the
> servo motor I am trying to control starts shaking. Now, I fill stuck
> and hope to get some help here.
>
> At one hand, I can not imaging that 800MHz ARM (BeagleBoard xM) could
> not manage to generate 20mS PWMs from RTDM driver precise enough to
> avoid sporadic servo movements. So probably I am doing something
> wrong. On the other hand, I do not see where the possible mistake can
> happen and hope that someone experienced in with Xenomai could help.
>
> There is an article about observed behavior [3] with more details, but
> the core problem, I guess, boils down to the following code fragment:
>
> void pwm_task_proc(void *arg) {
> const int which = (int)arg;
>
> // Toggling GPIO pin
> for(;;) {
> //set_data_out has offset 0x94 . Set gpio pin to 1 (up)
> iowrite32(0x4000, gpio + 0x6094);
>
> // wait requested pulse width time (duty)
> if(0 != rtdm_task_sleep(up_period[which]))
> rtdm_printk("PWM: rtdm_task_sleep() returns error\n");
>
> //clear_data_out has offset 0x90 . Set gpio pin to 0 (down)
> iowrite32(0x4000, gpio + 0x6090);
>
> // wait until the next pulse should start (20mS interval)
> if(0 != rtdm_task_wait_period())
> rtdm_printk("PWM: rtdm_task_wait_period() returns error\n");
> }
>
> This is the function running as a periodic task started with the following
> call:
>
> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
> element in this array
> "pwm-task",
> pwm_task_proc,
> 0,
> RTDM_TASK_HIGHEST_PRIORITY,
> 2000); // 20ms period
Do not use a thread, use a timer.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one >> element in this array >> "pwm-task", >> pwm_task_proc, >> 0, >> RTDM_TASK_HIGHEST_PRIORITY, >> 2000); // 20ms period > > Do not use a thread, use a timer. So you mean instead of starting periodic task with rtdm_task_init() it is better use timer functions to trigger pin toggling piece of code? Could you please elaborate on it a little? I thought that rtdm_task_sleep() and rtdm_task_wait_period() are using timers internally to wake up the thread at the right moment. Is not they? Is not it a kind of work-around you suggesting? If there are some problems which led to the imprecise timing of the sleep/wait functions mentioned above, then, if technically possible, it would be better to fix them instead of working around this behavior. Anyway, I am really appreciate your help and will try to rewrite this functionality using timer functions. Thank you very much, Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:27 PM, Gilles Chanteperdrix wrote:
> On 04/23/2012 01:56 PM, Andrey Nechypurenko wrote:
>> Hi Folks,
>>
>> Following my tests with PWM generation using GPIO in user space [1],
>> I've made the RTDM module [2] to further reduce the jitter. As a
>> result, jitter was improved, but still under heavy system load the
>> servo motor I am trying to control starts shaking. Now, I fill stuck
>> and hope to get some help here.
>>
>> At one hand, I can not imaging that 800MHz ARM (BeagleBoard xM) could
>> not manage to generate 20mS PWMs from RTDM driver precise enough to
>> avoid sporadic servo movements. So probably I am doing something
>> wrong. On the other hand, I do not see where the possible mistake can
>> happen and hope that someone experienced in with Xenomai could help.
>>
>> There is an article about observed behavior [3] with more details, but
>> the core problem, I guess, boils down to the following code fragment:
>>
>> void pwm_task_proc(void *arg) {
>> const int which = (int)arg;
>>
>> // Toggling GPIO pin
>> for(;;) {
>> //set_data_out has offset 0x94 . Set gpio pin to 1 (up)
>> iowrite32(0x4000, gpio + 0x6094);
>>
>> // wait requested pulse width time (duty)
>> if(0 != rtdm_task_sleep(up_period[which]))
>> rtdm_printk("PWM: rtdm_task_sleep() returns error\n");
>>
>> //clear_data_out has offset 0x90 . Set gpio pin to 0 (down)
>> iowrite32(0x4000, gpio + 0x6090);
>>
>> // wait until the next pulse should start (20mS interval)
>> if(0 != rtdm_task_wait_period())
>> rtdm_printk("PWM: rtdm_task_wait_period() returns error\n");
>> }
>>
>> This is the function running as a periodic task started with the following
>> call:
>>
>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
>> element in this array
>> "pwm-task",
>> pwm_task_proc,
>> 0,
>> RTDM_TASK_HIGHEST_PRIORITY,
>> 2000); // 20ms period
>
> Do not use a thread, use a timer.
>
So, rtdm_timer_init
If this still has too much overhead, you can use the OMAP3 API do
dedicate a GPTIMER to this task, and simply register an irq for the
GPTIMER which does the job (as opposed to a timer created with
rtdm_timer_init).
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:35 PM, Andrey Nechypurenko wrote: >>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one >>> element in this array >>> "pwm-task", >>> pwm_task_proc, >>> 0, >>> RTDM_TASK_HIGHEST_PRIORITY, >>> 2000); // 20ms period >> >> Do not use a thread, use a timer. > > So you mean instead of starting periodic task with rtdm_task_init() it > is better use timer functions to trigger pin toggling piece of code? > Could you please elaborate on it a little? I thought that > rtdm_task_sleep() and rtdm_task_wait_period() are using timers > internally to wake up the thread at the right moment. Is not they? Yes, but once the timer is woken up, a context switch is needed to wake up the thread, this adds time. > > Is not it a kind of work-around you suggesting? If there are some > problems which led to the imprecise timing of the sleep/wait functions > mentioned above, then, if technically possible, it would be better to > fix them instead of working around this behavior. No, the time it takes to switch context between threads is unavoidable. So, if you want to avoid it, you have to use a timer (rtdm_timer_init), note that it is really common in RTOS interfaces to offer a timer API, this is not a workaround at all. The other alternative I describe in my last mail, that is, using a dedicated hardware timer with its own irq handler, is a bit more of a workaround, but still not uncommon in the RTOS world. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
retval = rtdm_task_init(&pwm_task[i], // there is currently only one element in this array "pwm-task", pwm_task_proc, 0, RTDM_TASK_HIGHEST_PRIORITY, 2000); // 20ms period >>> >>> Do not use a thread, use a timer. >> >> So you mean instead of starting periodic task with rtdm_task_init() it >> is better use timer functions to trigger pin toggling piece of code? >> Could you please elaborate on it a little? I thought that >> rtdm_task_sleep() and rtdm_task_wait_period() are using timers >> internally to wake up the thread at the right moment. Is not they? > > Yes, but once the timer is woken up, a context switch is needed to wake > up the thread, this adds time. I see... Nevertheless, I am surprised that context switch is so expensive. > The other alternative I describe in my last mail, that is, using a > dedicated hardware timer with its own irq handler, is a bit more of a > workaround, but still not uncommon in the RTOS world. Well, if nothing else would help, I'll try this way :-) . Thank you! Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:51 PM, Gilles Chanteperdrix wrote: > On 04/23/2012 02:35 PM, Andrey Nechypurenko wrote: retval = rtdm_task_init(&pwm_task[i], // there is currently only one element in this array "pwm-task", pwm_task_proc, 0, RTDM_TASK_HIGHEST_PRIORITY, 2000); // 20ms period >>> >>> Do not use a thread, use a timer. >> >> So you mean instead of starting periodic task with rtdm_task_init() it >> is better use timer functions to trigger pin toggling piece of code? >> Could you please elaborate on it a little? I thought that >> rtdm_task_sleep() and rtdm_task_wait_period() are using timers >> internally to wake up the thread at the right moment. Is not they? > > Yes, but once the timer is woken up, a context switch is needed to wake > up the thread, this adds time. > >> >> Is not it a kind of work-around you suggesting? If there are some >> problems which led to the imprecise timing of the sleep/wait functions >> mentioned above, then, if technically possible, it would be better to >> fix them instead of working around this behavior. > > No, the time it takes to switch context between threads is unavoidable. > So, if you want to avoid it, you have to use a timer (rtdm_timer_init), > note that it is really common in RTOS interfaces to offer a timer API, > this is not a workaround at all. > > The other alternative I describe in my last mail, that is, using a > dedicated hardware timer with its own irq handler, is a bit more of a > workaround, but still not uncommon in the RTOS world. > Another trick, which this time really is a workaround is to program the timers to wake up a little bit early, and spin to wait for the exact time wanted. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
> Another trick, which this time really is a workaround is to program the > timers to wake up a little bit early, and spin to wait for the exact > time wanted. Sounds like the black magic exercise! :-) I would try to stay on the bright side as long as I can :-) Thanks Gilles! It is really great to have such quick response from you! ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:57 PM, Andrey Nechypurenko wrote: retval = rtdm_task_init(&pwm_task[i], // there is currently only one element in this array "pwm-task", pwm_task_proc, 0, RTDM_TASK_HIGHEST_PRIORITY, 2000); // 20ms period Do not use a thread, use a timer. So you mean instead of starting periodic task with rtdm_task_init() it is better use timer functions to trigger pin toggling piece of code? Could you please elaborate on it a little? I thought that rtdm_task_sleep() and rtdm_task_wait_period() are using timers internally to wake up the thread at the right moment. Is not they? Yes, but once the timer is woken up, a context switch is needed to wake up the thread, this adds time. I see... Nevertheless, I am surprised that context switch is so expensive. Keep in mind that in a dual kernel system, the RTOS part is competing with the linux kernel on core resources such as CPU caches. So each time your code sleeps for the next period, it leaves a 20 ms time window to linux to run and happily trash all I/D caches, which is a lot. Now, if you have to schedule a thread, you have to traverse the Xenomai scheduling core to do the switch, in addition to the timer interrupt handling, which translates into significantly more code and data being accessed. You can check this effect using the latency test: the faster the sampling period, the shorter the latencies, and conversely. The other alternative I describe in my last mail, that is, using a dedicated hardware timer with its own irq handler, is a bit more of a workaround, but still not uncommon in the RTOS world. Well, if nothing else would help, I'll try this way :-) . Thank you! Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 01:56 PM, Andrey Nechypurenko wrote: > Hi Folks, > > Following my tests with PWM generation using GPIO in user space [1], > I've made the RTDM module [2] to further reduce the jitter. As a > result, jitter was improved, but still under heavy system load the > servo motor I am trying to control starts shaking. Now, I fill stuck > and hope to get some help here. What jitters in micro-seconds are you speaking about? What are you requirements? I have not found that information yet in this thread. Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
>> Following my tests with PWM generation using GPIO in user space [1], >> I've made the RTDM module [2] to further reduce the jitter. As a >> result, jitter was improved, but still under heavy system load the >> servo motor I am trying to control starts shaking. Now, I fill stuck >> and hope to get some help here. > > What jitters in micro-seconds are you speaking about? What are you > requirements? I have not found that information yet in this thread. The short answer is - I do not know exactly :-) . The long answer is - my goal is to keep servo motor stable under the high system load. I was unable to find any concrete numbers regarding the tolerance level of the no-name servo motor. So I am just experimenting. My recent observations, presented in the blog I've mentioned in the original post, suggest that 20-30micro-seconds jitter will force my concrete servo to start the movements. I was unable to further reduce jitter, so maybe this number is actually lower. I will try to implement what Gilles suggested (using timer api) and see if I can a) further reduce jitter; and b) if this jitter will be small enough to prevent servo from shaking. Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 03:25 PM, Andrey Nechypurenko wrote: >>> Following my tests with PWM generation using GPIO in user space [1], >>> I've made the RTDM module [2] to further reduce the jitter. As a >>> result, jitter was improved, but still under heavy system load the >>> servo motor I am trying to control starts shaking. Now, I fill stuck >>> and hope to get some help here. >> >> What jitters in micro-seconds are you speaking about? What are you >> requirements? I have not found that information yet in this thread. > > The short answer is - I do not know exactly :-) . > > The long answer is - my goal is to keep servo motor stable under the > high system load. I was unable to find any concrete numbers regarding > the tolerance level of the no-name servo motor. So I am just > experimenting. My recent observations, presented in the blog I've > mentioned in the original post, suggest that 20-30micro-seconds jitter > will force my concrete servo to start the movements. You can run Xenomai's latency test under load to get an idea what you can achieve on that system... and it will be more than 20-30us. Also try the -t1 and t2 options. > I was unable to further reduce jitter, so maybe this number is > actually lower. I will try to implement what Gilles suggested (using > timer api) and see if I can a) further reduce jitter; and b) if this > jitter will be small enough to prevent servo from shaking. The timer anticipation trick Gilles suggested would work fine, I think, whithout costing too much (as your period is just 20ms). Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Using rt_dev_send from user space
Hi, The short story is that I tried to call rt_dev_send on a CAN RTDM driver, and it fails with an EPERM (Operation not permited) return code. It's as if I was using rtcansend without the "RT_TASK rt_task_desc;". Is it an intended behavior ? Do I have a way to configure this to be accessible from user space ? Do I have to call rt_task_shadow ? The long story is that I have a fully operationnal robot communicating over CAN with CanFestival with gluninux timers in the Orocos framework (only compiled for gnulinux). As it is showing CAN loop delays depending on CPU load, I am trying to switch CanFestival to xenomai in order to have a primary mode CAN SYNC timer, keeping my Framework Orocos out of xenomai (cause it is not stable in my version under xenomai). The problem is (I think) that none of my tasks are in xenomai primary mode, exept the CAN SYNC timer. As I would like to avoid using xenomai much before this summer, I'm looking for a simple way to send messages to rtcan driver from user space. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_event_wait makes linux crash if executed while debugging with gdbserver
On 04/13/12 16:49, Fabio Visona wrote:
Hello,
I am trying to debug a Xenomai task through gdbserver over ethernet, with:
gdbserver host:12345 --attach 240
where 240 is the PID of the Xenomai real-time task I want to debug.
After connecting with the gdb client, running continuosly is fine, but
if I put a breakpoint and afterwards make the software execute an
rt_event_wait call, the system crashes (gdb client stuck, no more
ethernet connection, no panic message on the debug console serial port).
By going step by step with the debugger, the exact point of the problem
can be isolated:
int rt_event_wait(RT_EVENT *event,
unsigned long mask,
unsigned long *mask_r, int mode, RTIME timeout)
{
int ret;
ret = XENOMAI_SKINCALL5(__native_muxid,
__native_event_wait,
event, &mask, mode, XN_RELATIVE, &timeout);
if (ret)
return ret;
*mask_r = mask;
return 0;
}
with mode = EV_ANY, timeout is 1 - 10 ns about.
Showing the assembly code of the XENOMAI_SKINCALL5 macro:
0x64fc4e : R3 = 0x0 (X); /* R3=0x0( 0) */
0x64fc50 : R7.L = 0x22b; /* (555)
R7=0x0x27022b(2556459) */
0x64fc54 : JUMP.S 0x0x64fc60 ;
0x64fc56 : R0 = P1;
0x64fc58 : R1 = -0x55 (X); /* R1=0x0xffab(-85) */
0x64fc5c : CC = R0 == R1;
0x64fc5e : IF !CC JUMP 0x0x64fc9e ;
0x64fc60 : [FP + -0x848] = R3;
0x64fc64 : R1 = R6;
0x64fc66 : R2 = P4;
0x64fc68 : R0 = [P5];
0x64fc6a : R0 = R0 | R7;
0x64fc6c : P0 = R0;
0x64fc6e : R0 = P3;
0x64fc70 : EXCPT 0x0;
<<
0x64fc72 : P1 = R0;
0x64fc74 : R0 = [FP + -0x848];
Execution crashes at EXCPT 0x0, which should be a system call, according
to Xenomai sources (syscall.h).
Xenomai version is 2.5.3, Linux 2.6.34.7, running on a Blackfin BF518
processor.
Note that everything works fine running the application without debugger.
Any hint?
This could be a pipeline (adeos) issue, or a Xenomai core issue.
Quite a bunch of nasty bugs were fixed since 2.5.3, and the interrupt
pipeline patch shipped with this release in ksrc/arch/blackfin/patches.
Some of them were even specific to ptracing a Xenomai application.
For narrowing the issue, I would suggest the following steps, incrementally:
- to upgrade the pipeline to this one, in case you are running any
earlier version:
http://download.gna.org/adeos/patches/v2.6/blackfin/older/adeos-ipipe-2.6.34-blackfin-1.15-01.patch
If the issue still shows up:
- to upgrade the Xenomai stack to 2.5.6.
I have a pipeline upgrade pending for the 3.2/blackfin kernel, so I'd be
interested to know whether that gremlin still hides in recent releases,
so that I might fix it prior to issuing that patch. I don't have any
bf518 at hand, but if you have any simple test code reproducing the
issue to send me, I could try it on my oldish bf561 in single core mode.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
