[ECOS] Changing system timer resolution

Jonathan Larmour jlarmour@redhat.com
Fri Nov 30 17:51:00 GMT 2001

Gary Thomas wrote:
> On Wed, 2001-11-28 at 10:19, Jurica Baricevic wrote:
> > Grant Edwards wrote (Wednesday, November 28, 2001 17:28):
> > > I've gotten repeated requests from customers for different
> > > (generally smaller) system timer resolutions.  Changing the
> > > timer resolution is easy enough, but doing so breaks things
> > > things since a lot of application level code (system tests, TCP
> > > stack, DHCP task, etc.) depends on the assumption that a system
> > > timer tick is 10ms.  [This assumption seems like a fairly
> > > fundamental flaw for RTOS application code.]

If you are saying that any eCos code assumes that (TCP/DHCP) please let us

> > > It would be awfully nice if there were a simple way for an
> > > application to determine the system timer tick resolution (e.g.
> > > macros/functions to convert back and forth between
> > > seconds<->ticks and ms<->ticks).  I know this information is
> > > available, but it's buried pretty deeply and is difficult to
> > > use.
> >
> > I absolutely agree with the statement above. Currently, I am using some
> > "home-made" calculations and macros in my applications (i.e. for
> > cyg_thread_delay()) and they look quite awkward. Some 'easy to use'
> > conversion between real time and system tick in any form (API, macro) would
> > be quite useful.
> >
> Agreed.

<AOL> Me too! </AOL>

I think some care would need to be taken that overflow, underflow and loss
of precision is avoided though - there can be both very big and very small
numbers involved! Look at the hoops the "clock convertors" have to go
through in kernel/current/src/common/clock.cxx for example! Although it
wouldn't be as extreme as that fortunately.
> > Digression:
> > Also, it would be nice to have some high-resolution performance counter for
> > more precise time handling. For example, microsecond handling is quite
> > common in today's RTOS applications. The high-resolution counter shouldn't
> > be limited by system timer tick resolution, but with the underlying hardware
> > clock resolution.
> This is already available using the HAL_CLOCK_READ() functionality.
> Look for examples of how to use it in the 'tm_basic.cxx' test program.

You do still have to know what it means though in real time (although in
turn, translating to seconds takes up time - which prevents the value read
being as accurate!)

Grant says about wanting an event to happen 7354us from now. I assume you
mean do a busy poll for that since a timer tick isn't that accurate.... or
at least wait the prerequisite number of ticks and then poll.

I think we are pretty close to that in the delay_us function (currenbtly it
is purely a busy poll). The only problem is that that function doesn't have
an exposed (kernel C) API. As Jurica mentions, perhaps gettimeofday() would
be adequate, although by doing that, you'll probably pull in POSIX baggage,
so for now a kernel C API function may be better. "All" it would have to do
is call CYGACC_CALL_IF_DELAY_US(usecs) from hal_if.h. Although that does
rely on virtual vector support. Hmm...

> > > Things like TCP and DHCP could then be written so that they
> > > work with any system tick resolution.
> > >
> > > If there were macros to convert between "real-world" time and
> > > system ticks, how many places would those need to be inserted
> > > for an eCos system to "just work" when the system timer
> > > resolution is changed?
> > >
> > > Would a change like this make it into the standard source tree?
> >
> > I believe that eCos community would benefit from this change.

I think I'd probably accept a (carefully written) patch avoiding the
problems I mention above.

Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

More information about the Ecos-discuss mailing list