public inbox for
 help / color / mirror / Atom feed
From: Ken <>
Subject: Re: timer idioms in embedded system
Date: Fri, 03 Jul 1998 00:49:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Aerospace Software wrote:
> Hi Ken,
> From a code maintenance point of view, it is better to have a separate SW
> timer for each and every event that needs timing.  In order to get a picture
> of what the system is doing, simply take a snapshot of the timers. This
> method is akin to a finite state machine and has the same good
> characteristics - all events and states are defined and nothing unexpected
> can possibly happen.
> I infer from you example that you are probably using a single code
> thread/task -whatever you want to call it. If you are using a multi tasking
> system, then waiting for a timer to expire in a tight loop is not a good
> idea, since the system could have used the time to do something else.

Correct. The current system is a single thread that updates several
state machines (eg. command parser, system state).
> Consider implementing a simple scheduler - round robin, run to completion is
> usually good enough. Let the tasks communicate with each other through
> either message passing and queues (if it is important that the sequence of
> event be preserved) or with a bulletin board of semaphores/flags (if the
> sequence of events are not important). Keep the system exclusively event
> driven based upon these inputs and never ever make it sit in a wait loop.

That's my ultimate plan when I ultimately change platforms, but the
current platform is severely memory-limited and there's no room for an

> Your timer interrupt handler could then communicate with the tasks either by
> posting a message to a queue, or setting a flag, or calling a procedure (for
> regular repetitive events).
> Note that you already have a 'single counter' as you were thinking of.  This
> is non other than the HW counter used to create the interrupt tick and it is
> rather inconvenient to use from a SW point of view. Therefore, it is safe to
> assume that if you simply use the HW counter as a prescaler to another SW
> timer, it will remain equally inconvenient!
> The trick is to optimise the timer code such that the system can scan the
> active timers very quickly and only spend appreciable time on the ones that
> are active.

For limited memory, it's actually pretty optimized now. With more RAM, I
could implement separate tasks with their own stacks and timer delta
lists as described in the 2nd volume of _Internetworking with TCP/IP_.

> Ken wrote:
> > I'm trying to come up with a good timer idiom that doesn't use much
> > interrupt time.
> >
> > My current code (single-threaded, no RTOS) uses an array of words to
> > represent global timers.  The timer interrupt decrements any non-zero
> > timers. Code that wants to use a timer sets it to a non-zero tick count
> > and then waits for it to decrement to zero with a simple "while (timer)
> > ;".
> >
> > I'd like to change this to use a single counter incremented by the
> > interrupt. Client code would wait for the counter to increment to a
> > desired value. Example wait code might be
> >
> >  unsigned long expire_time = clock() + delay;
> >  while (clock() < expire_time) /* wait */;
> >
> > How should I handle rollover? I expect the counter to be 32-bit, and the
> > interrupt tick to be 1 millisecond. The rollover should occur about
> > every 46 days.
> >
> > It seems like I could declare the 32-bit values as signed and do
> > something like
> >
> >  long clock();
> >  long expire_time = clock() + delay;
> >  while ((clock() - expire_time) < 0) /* wait */;
> >
> > Is this reasonable?

mailto:shiva@CompuServe.COM (Death to Spam!)

  parent reply	other threads:[~1998-07-03  0:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-25 21:10 Ken
     [not found] ` <>
1998-07-03  0:49   ` Ken [this message]
1998-06-26  7:13 Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).