This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Changing system timer resolution
- From: Gary Thomas <gthomas at redhat dot com>
- To: Jurica Baricevic <jura at INTESIS dot hr>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>,Grant Edwards <grante at visi dot com>
- Date: 28 Nov 2001 10:31:07 -0700
- Subject: RE: [ECOS] Changing system timer resolution
- References: <NFBBJGOLDDDGJPLCMJKNCEIFCCAA.jura@intesis.hr>
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.]
> >
> > 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.
> 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.
>
>
> > 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.
>
>
> > If not, I don't think I want to fork my own version and have to
> > support it ad inifinitum -- I'll just have to tell those
> > customers they're out of luck if they don't like 10ms timer
> > ticks.
> >
> > --
> > Grant Edwards
> > grante@visi.com
> >
>
>
> Best regards,
> Jurica Baricevic