public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Scott Dattalo <scott@dattalo.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] simple eCos profiler
Date: Wed, 31 Jul 2002 04:55:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0207310445570.17284-100000@ruckus.brouhaha.com> (raw)
In-Reply-To: <20020731101345.GF3392@biferten.ma.tech.ascom.ch>

On Wed, 31 Jul 2002, Andrew Lunn wrote:

> > Yep, you're right:
> > 
> > My profiler is based on the system tick interrupt.  I AM aware of
> > the inherit problems of doing it this way but this was the most
> > portable way of doing it.  For a heavily loaded system, doing it
> > this way shouldn't skew results too much I don't think.
> 
> When i wrote my profiler i did not like the idea of using the system
> tick interrupt, even thought its more portable. Timer actions will be
> triggered by the timer tick, which have an important affect on the
> flow of execution in an RTOS. Thus your profiler will give squewed
> results which tend to show more of the low priority background tasks
> which are always running and less of the higher priority tasks which
> are general somehow linked to the system clock. 
> 
> I used a second timer which i set to run at a different frequency
> which is not a multiple of the system clock. This should give more
> accurate results. The down side is its less portable since it has to
> play around with the hardware to setup this timer.
> 
> What would be nice is to split the code into two halfs. One to setup
> the interrupts etc, which would be hardware dependent and the second
> half to actually do the logging. We could provide a generic version
> using the system tick and the option to add hardware specific
> implementations using other timers.


Along these lines, may I suggest yet another way? Would it be difficult to
decouple the profiling process from the timer source in such a way that
you could either dynamically or at compile time select the sampling
stimulus. For example, for an old microcontroller application I used an
interrupt pin to trigger the profiler. The interrupt routine did nothing
more than examine the call stack to extract where the code was executing
and copied this into a circular buffer. It's not exactly a profiler, but
it can gave me a rough idea of where the processor was spending its time.

Perhaps, Andrew, this is what you already mean by splitting the code into 
two halves?

Scott


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

  reply	other threads:[~2002-07-31 11:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 22:20 NavEcos
2002-07-31  1:05 ` Andrew Lunn
2002-07-31  1:38   ` NavEcos
2002-07-31  2:02     ` Andrew Lunn
2002-07-31  2:54       ` NavEcos
2002-07-31  3:13         ` Andrew Lunn
2002-07-31  4:55           ` Scott Dattalo [this message]
2002-07-31  5:19         ` Gary Thomas
2002-08-01  3:05     ` NavEcos

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0207310445570.17284-100000@ruckus.brouhaha.com \
    --to=scott@dattalo.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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