This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Changing system timer resolution


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.

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.


> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]