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


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