Re: [Xenomai-help] Xenomai stop working

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 03/13/2012 07:32 AM, 马强 wrote:
> Hi, Gilles.
> 
> I could not find "mxc_min_delay = 0xff" in linux source tree 
> and xenomai directory. mxc_min_delay comes from ipipe, 
> there is also no such statement in latest patch downloaded 
> from website.
> 
> If mxc_min_delay is 0xff, in my system this means 32us for 8MHz 
> ipipe tsc. For a real time system, It seems a little bit longer.
> 
> I used mxc_min_delay=16(2us) to do a test during last weekend, 
> until now and no stall have happened again. So mxc_min_delay = 0x10 
> maybe enough for my test CPU, I can't decide which value should be used.

Linux uses a similar mechanism for its clock_event_device named
min_delta_ns. In latest releases min_delta_ns is set such that it
corresponds to 0xff ticks. But you are right: this value is too large
for xenomai.

> 
> The following code copy from the time.c file that patched by xenomai.
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> 	if (delay > mxc_min_delay) {
> 		unsigned long tcmp;
> 
> 		if (!timer_is_v2()) {
> 			tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
> 			__raw_writel(tcmp, timer_base + MX1_2_TCMP);
> 		} else {
> 			tcmp = __raw_readl(timer_base + V2_TCN) + delay;
> 			__raw_writel(tcmp, timer_base + V2_TCMP);
> 		}
> 	} else
> 		ipipe_trigger_irq(__ipipe_mach_timerint);
> }
> 
> My question is whether this function will be interrupted by other high priority interrupts.

No, this function is called with hardware irqs off.

-- 
                                                                Gilles.