[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rt
Subject:    Re: [Rtl] rt_com call-back function
From:       "Wayne E. Van Loon Sr." <wevl () pacifier ! com>
Date:       2005-02-19 20:29:47
Message-ID: 4217A1BB.2080106 () pacifier ! com
[Download RAW message or body]

Dear Pieter:
This may not apply to you at all, but...
In one application where I occasionally need to synchronize, I run a 
standard period until the time left to the synchronization event is less 
than 1 standard period. I have an array of structures where I store the 
time at which these events need to happen, what type of event it is, etc.

struct RT_EVENT {
   hrtime_t time;
   unsigned long cmd;
   .......
};

struct RT_EVENT rt_event[MAX_EVENTS];

Every run, I 		

ghrtime = gethrtime();
shortest_time = ghrtime + PERIOD; /* This is the time for our next 
scheduled run. */

then parse through the pending rt_events looking for the closest one 
that needs to happen before the next scheduled run.

e = -1;
for( i=0; i<MAX_EVENTS]; i++ ){
	if( !rt_event[i].time )continue;
	if( rt_event[i].time < shortest_time ){
        		shortest_time = rt_event[i].time
		e = i; /* save a index */
	}
}
if( e >= 0 ){
        pthread_make_periodic_np( pthread_self(), ghrtime,
			         rt_event[e].time - ghrtime  );

I also set a flag so that when we next run the main loop, we know to wait. 	

        rte_state = 2;/* Tweaking the period one time.. */
}

At the top of my main loop:
if(rte_state == 2){
	rte_state = 1;
	pthread_wait_np();/* Now we wait the irreguralr period */
}

The thread will still respond to hardware interrupts and will continue 
after the synchronization interval at which time I perform the 
rt_event(s). If I don't need to immediately synchronize to another real 
time event, I resume the regular period.

I could have restarted the standard period after the irregular interval 
like this:

        pthread_make_periodic_np( pthread_self(), rt_event[e].time,
			          PERIOD );

But I have found that my threads will not respond to hardware interrupts 
while waiting to restart. Your mileage may vary.

Wayne



Pieter van der Meer wrote:
> Hi Stephen,
> 
> Thanks for your reply! :)
> 
> Your advice is interesting! Actually, I first suspected nanosleep to
> be the cause of the system clock malfunction, because it turns off
> interrupts for a while. But it turned out it was really the rt_com
> call-back function. I called "pthread_wakeup_np()" from this
> call-back. Does anyone know whether this is healthy?
> 
> I now use periodic timing (100 microsecond interval) to get the
> communication responsive.
> I still use nanosleep every because we require one-shot behaviour to
> synchronise to an external 100 Hz clock with sub-milisecond precision.
> And it seems, even after long tests that there are no more system
> clock jumps. Replacing this method of syncing with periodic timing
> might be a possibility... Does anyone else have preferences for
> nanosleep or periodic timing, respectively?
> 
> With kind regards,
> 
> Pieter van der Meer
> 

_______________________________________________
Rtl mailing list
Rtl@rtlinux.org
http://www2.fsmlabs.com/mailman/listinfo/rtl
[prev in list] [next in list] [prev in thread] [next in thread]