This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: simple eCos profiler
- From: Scott Dattalo <scott at dattalo dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Wed, 31 Jul 2002 04:55:39 -0700 (PDT)
- Subject: Re: [ECOS] simple eCos profiler
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