Re: [Xenomai] usage of rtdm_task_sleep_abs

[Johann Obermayr <johann.obermayr@sigmatek.at>]

Am 13.07.2015 um 21:58 schrieb Gilles Chanteperdrix:
> On Mon, Jul 13, 2015 at 07:26:11PM +0200, Johann Obermayr wrote:
>> Am 13.07.2015 um 19:21 schrieb Gilles Chanteperdrix:
>>> Johann Obermayr wrote:
>>>> Am 13.07.2015 um 17:24 schrieb Gilles Chanteperdrix:
>>>>> Johann Obermayr wrote:
>>>>>> without your application, there are no large latencies.
>>>>>> with your application see frozen.txt (with latency -f)
>>>>> I am confused. You mean "our application", not "your application",
>>>>> right?
>>>>> lrtdrv_monitoring_irq is not part of the code delivered by the Xenomai
>>>>> project.
>>>>>
>>>>>> We see the problem only if one task (background) is accessing the SRAM
>>>>>> on your PCI-Card. if we stop this task, all is ok.
>>>>> Again: the Xenomai project does not make PCI-card. So, you probably mean
>>>>> "our PCI-Card"?
>>>> yes, our PCI-Card. (sorry for my bad english)
>>>>>> So we have a higher prior task (pci-locker), that interrupt the
>>>>>> background task, so that the pci bus get free.
>>>>> I am not sure I understand your explanations. But the trace is pretty
>>>>> clear:
>>>>>
>>>>> At time -658 the timer is programmed to tick at -561.
>>>>>
>>>>>> :|  # event   tick@-561   -658	  0.112  xntimer_next_local_shot+0xca
>>>>>> :|  + func                -651	  0.145  lrtdrv_monitoring_irq+0x4
>>>>>> [sigmatek_lrt] (irq_hook_handler+0x32 [sigmatek_lrt])
>>>>>> :|  + end     0x000000ef  -651! 641.640  apic_timer_interrupt+0x52
>>>>>> (<102d0254>)
>>>>> But at that point the tick is delayed for 600us. And according to the
>>>>> trace, the last traced function called before that delay is the function
>>>>>
>>>>> ltdrv_monitoring_irq.
>>>>>
>>>>> So, I do not know what this irq is doing, but I would suggest having a
>>>>> close look at it.
>>>>>
>>>>>
>>>> hello,
>>>>
>>>> i have disable our lrtdrv_monitoring_irq.
>>>> Only have this callback
>>>> static void irq_hook_handler(unsigned int irq, unsigned int state)
>>>> {
>>>>       if (fpga_interrupt == irq && state == 0x01)
>>>>       {
>>>>           time_fpga_irq = rt_timer_tsc();
>>>>       }
>>>> }
>>>> same latency
>>> Maybe, but your trace does not contain enough points to see it. The trace
>>> should at least contain the "tick@" event which gets missed, so that we
>>> can see how much the interrupt is delayed, and what was happening at the
>>> time.
>>>
>>>
>> Hi,
>>
>> Sorry, here with more points.
> Ok, what is irq_hook_handler ?
>
Ok.  on out PCI Card there is a FPGA. This FPGA generate am Interrupt to 
the PC. But internal in the FPGA there
are different IRQ sources. One of them is our Tick.
So we measure the time from  __ipipe_handle_irq to the  our 
rtdm_irq_request handler.
In our handler we can check, if it our Tick and than we can calc the 
correct time to start our pci_locker task 50us before next Tick-irq.

It's a callback function from some irq function ipipe_raise_irq, 
__ipipe_do_IRQ, __ipipe_handle_irq
for our own tracing and it save the fpga irq time.
Only __ipipe_handle_irq have state 0x01 (begin irq) & state 0x02 at the 
end of the function.

Regards
   Johann