Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: asynDriver / epicsTimer bug
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: tech-talk@aps.anl.gov
Date: Tue, 30 May 2006 22:39:31 +0200
On Tuesday 30 May 2006 19:05, Jeff Hill wrote:
> > I think, a timer should wait at least the specified amount of time,
> > thus always round up to at least one tick.
>
> When the timer is installed its absolute expiration time is recorded
> as an EPICS time stamp. If the current time grows to be greater than
> the timer's absolute expiration time, the timer's expiration callback
> is called.
>
> > I think it is actually a problem with epicsTimer, which never
> > expires for timeouts < 1/sysClkRateGet(). But I have not tested
> > this.
>
> This appears, from a source code perspective, to be unlikely based on
> the way the timer library is implemented. However, the scenario you
> describe should be fairly obvious in a stack trace and I am happy to
> look at your stack trace should there be evidence to the contrary.
>
> PS: If timer expiration callbacks are not running be sure to look for
> a user code that is stuck, for whatever reason, in a timer expiration
> callback.

Another source of the problem could be that somehow it happens that 
interrupts are disabled, so no clock ticks occur (I know it's quite 
improbable but never hurts to check).

BTW (and maybe OT, but anyway): Many years ago we badly needed a way to 
set up alarms with far greater resolution than provided by vxWorks' 
clock ticks. So Ralph Lange wrote a library that used the additional 
timer chip available on mv162 boards to provide microsecond resolution 
timers. Two years ago Christi Luchini ported it to PowerPC boards 
mv2100 and mv2400 and separated out the BSP dependent low-level stuff 
from the high-level timer logic. It is now also ported to EPICS R3.14 
build system (but still depends on vxWorks). It was originally part of 
our MultiCAN package but was separated out long ago; it seems we never 
went around to set up a web-page and annouce it as a separately 
available module. I am going to fix this, hopefully during the next 
week. You'll be able to download it via 
http://www-csr.bessy.de/control/SoftDist/, probably under 
subdirectory 'almLib', but there'll be a link, too.

Cheers,
Ben

References:
RE: asynDriver / epicsTimer bug Jeff Hill

Navigate by Date:
Prev: RE: asynDriver / epicsTimer bug Jeff Hill
Next: Building a standalone IOC for an Intel embedded system Jon Brinkmann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: asynDriver / epicsTimer bug Jeff Hill
Next: Re: asynDriver / epicsTimer bug Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·