Re: rt_com call-back function

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


On Thu, 17 Feb 2005 13:46:42 +0200, Stephen Marchant <[email protected]> wrote:
> Hi there
> Never ever ever ever ever use nanosleep in rtl... trust me on this as I lost
> my development team 3 weeks by using it,
> it kills your system clock... and destroys the integraty of ALL interupt
> handling.
> 
> If you look in the rtl man pages it actualy tells you to never use it !
> 
> ... (  I'm sure you are going to hear from the whole dev team on this issue
> over the next few days lol.)
> 
> cheers Stephen Marchant
> 
> 
> ----- Original Message -----
> From: Pieter van der Meer <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, February 16, 2005 1:59 PM
> Subject: [Rtl] rt_com call-back function
> 
> > Hi everyone,
> >
> > Recently, I've tried to run serial communications in real-time using
> > RTLinux. For this I use the rt_com module. Since the module doesn't
> > offer blocking reads I made my own blocking read with time-out. I used
> > the call-back function to wake up my real-time thread when the UART's
> > read FIFO is triggered. The time-out feature was done by a nanosleep
> > with an interval proportional to the number of bytes to read. This
> > seemed to do the trick, and the whole thing runs very efficiently.
> >
> > However, when I looked I looked at the Linux system clock I noticed it
> > jumped around like a madman. Once of twice per minute it does jumps of
> > 4 seconds. After some investigation it seemed the rt_com call-back
> > function was the cause. I disabled the call-back and made the thread
> > periodic. This seemed to stop the jumps from occuring.
> >
> > The way it runs now is very satisfying. However, I still would like to
> > have some insight into the flaws of this call-back mechanism. My guess
> > is it disables interrupts for a long time, which causes the system
> > timer to malfunction? Can it be that "pthread_wakeup_np()" also
> > contributes to this effect? Does anyone share similar experiences?
> >
> > My setup is a 350 MHz PII with kernel 2.4.20, RTLinux 3.2-pre2, rt_com
> 0.5.5.
> >
> > Kind regards,
> >
> > Pieter van der Meer
> > _______________________________________________
> > Rtl mailing list
> > [email protected]
> > http://www2.fsmlabs.com/mailman/listinfo/rtl
> 
> 
>
_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl