public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
* Re: timer idioms in embedded system
@ 1998-06-26  7:13 Dave Hansen
  0 siblings, 0 replies; 3+ messages in thread
From: Dave Hansen @ 1998-06-26  7:13 UTC (permalink / raw)
  To: shiva, c++-embedded, shiva

If you stay in unsigned integer math, you can pretty much ignore 
rollover.  Signed math may bite you since it's not as well defined.

Change your client code to work something like:

   unsigned long start = clock();
   while ((clock()-start) < delay) wait();

For example, if start==0xFFFFFFF0 and clock() returns 4, the result
of the subtraction will be 4 - 0xFFFFFFF0 or 0x00000014

HTH.  Regards,

     -=Dave

>>> Ken <shiva@compuserve.com> 06/25/98 10:41PM >>>
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?

-- 
Ken
mailto:shiva@well.com 
mailto:shiva@CompuServe.COM 
http://www.well.com/user/shiva/ 
http://sewnsurf.home.ml.org/ 
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)




                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             !
                                   
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             !
                                   
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: timer idioms in embedded system
       [not found] ` <359B0170.D922E2B9@agt.net>
@ 1998-07-03  0:49   ` Ken
  0 siblings, 0 replies; 3+ messages in thread
From: Ken @ 1998-07-03  0:49 UTC (permalink / raw)
  To: egcs; +Cc: c++-embedded

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
RTOS.

> 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?

-- 
Ken
mailto:shiva@well.com
mailto:shiva@CompuServe.COM
http://www.well.com/user/shiva/
http://sewnsurf.home.ml.org/
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)





^ permalink raw reply	[flat|nested] 3+ messages in thread

* timer idioms in embedded system
@ 1998-06-25 21:10 Ken
       [not found] ` <359B0170.D922E2B9@agt.net>
  0 siblings, 1 reply; 3+ messages in thread
From: Ken @ 1998-06-25 21:10 UTC (permalink / raw)
  To: c++-embedded

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?

-- 
Ken
mailto:shiva@well.com
mailto:shiva@CompuServe.COM
http://www.well.com/user/shiva/
http://sewnsurf.home.ml.org/
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-07-03  0:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-06-26  7:13 timer idioms in embedded system Dave Hansen
  -- strict thread matches above, loose matches on Subject: below --
1998-06-25 21:10 Ken
     [not found] ` <359B0170.D922E2B9@agt.net>
1998-07-03  0:49   ` Ken

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).