On Mon, Jul 13, 2015 at 10:23:02PM +0200, Johann Obermayr wrote:
> 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.
The proper way to handle an interrupt which generates multiple IRQ
sources is with a "chained handler".
> 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
Ok, this is a bit ugly, and probably useless. The latency is not
between __ipipe_handle_irq and your handler, it is between the hardware
irq and __ipipe_handle_irq. And due to this latency, you must
calculate the "correct" time with some margin taking the latency
into account. And you must realize that you can not do anything from
such callback, such as calling xenomai functions.
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
