Jerry Avins wrote:
> Larry Martell wrote:
>
>    ...
>
> > I did not mean to imply this was a bad solution ... just a
different
> > one from what a software person would come up with
>
> To continue a bit in snide mode: I thought that even software people
did
> I/O.

Of course software people do I/O. My point was that as a software
person
my initial thoughts do not usually involve lowpass filters, meters, and
oscilloscopes. It's just like if you're sick and you go to a
traditional
western medical doctor then will give drugs, if you go to a surgon they
will operate, and if you go to a native american shaman they will give
you
herbs.

> Now for philosopher mode: software amounts to instructions for
hardware.
> While it may be possible to create instructions for for a structure
that
> one doesn't fully understand -- some officers and executives do that
--
> knowing what one is really doing is usually very beneficial.

I agree it's extremely beneficial, but very often not possible. I've
worked on many large software projects that for various reasons
management
activly prevented any one person from knowing the big picture or even
how
your piece was going to be used. I've also worked on software for
extremely complicated systems that I would never have a hope of
understanding.

-larry

Larry Martell wrote:

   ...

> I did not mean to imply this was a bad solution ... just a different
> one from what a software person would come up with

To continue a bit in snide mode: I thought that even software people did 
I/O.

Now for philosopher mode: software amounts to instructions for hardware. 
While it may be possible to create instructions for for a structure that 
one doesn't fully understand -- some officers and executives do that -- 
knowing what one is really doing is usually very beneficial.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:
> Larry Martell wrote:
> > Dan Mills wrote:
> >
> >>Larry Martell wrote:
> >>
> >>
> >>>I don't want to slow down any part of the system by doing this. I
> >>>am also timing some things on the P4 side too. Messages and data
> >
> > are
> >
> >>>being passed back and forth between the P4 and the DSP and if I
> >
> > stop
> >
> >>>and do some calculations it will skew the results.
> >>
> >>
> >>Humm, OK.
> >>Do you have a spare IO pin? set it high at the start of your time
> >
> > consuming
> >
> >>code then low at the end (probably one instruction each).
> >>Connect to simple RC lowpass filter and a meter and read off
> >
> > processor load
> >
> >>directly (or to a scope if you are looking for exact timing
details)!
> >
> >
> > At had to smile at this because a EE I work with suggested the same
> > thing.
> > He suggested it to a room full of programmers ... we all looked at
each
> >
> > other and smiled. And I said, "Well, that's a EE's solution ..."
> >
> > Thanks!
> > -larry
>
> Those who restrict the domain of solutions they accept get fewer
> workable solutions.

I did not mean to imply this was a bad solution ... just a different
one
from what a software person would come up with

-larry

Larry Martell wrote:
> Dan Mills wrote:
> 
>>Larry Martell wrote:
>>
>>
>>>I don't want to slow down any part of the system by doing this. I
>>>am also timing some things on the P4 side too. Messages and data
> 
> are
> 
>>>being passed back and forth between the P4 and the DSP and if I
> 
> stop
> 
>>>and do some calculations it will skew the results.
>>
>>
>>Humm, OK.
>>Do you have a spare IO pin? set it high at the start of your time
> 
> consuming
> 
>>code then low at the end (probably one instruction each).
>>Connect to simple RC lowpass filter and a meter and read off
> 
> processor load
> 
>>directly (or to a scope if you are looking for exact timing details)!
> 
> 
> At had to smile at this because a EE I work with suggested the same
> thing.
> He suggested it to a room full of programmers ... we all looked at each
> 
> other and smiled. And I said, "Well, that's a EE's solution ..."
> 
> Thanks!
> -larry

Those who restrict the domain of solutions they accept get fewer 
workable solutions.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Garrett wrote:
> This problem usually happens when you set the memory models 'near
calls
> & data' instead of 'far calls & data'. Check your CCS build
> options->compiler->advanced

Thanks for the reply. I have solved this - it was 2 different issues:
one was (as Tim has pointed out) that I simply had more things going
into IDRAM then would fit. When I moved some things around and re-sized
some things I got it to fit.

The second issue was as you said, that I was using a near memory model,
and I was trying to address beyond what that model would support.

This experience was very useful to me as I learned a lot about the
memory model and mapping of the devices.

Thanks to all who replied!
-larry

Dan Mills wrote:
> Larry Martell wrote:
>
> > I don't want to slow down any part of the system by doing this. I
> > am also timing some things on the P4 side too. Messages and data
are
> > being passed back and forth between the P4 and the DSP and if I
stop
> > and do some calculations it will skew the results.
>
>
> Humm, OK.
> Do you have a spare IO pin? set it high at the start of your time
consuming
> code then low at the end (probably one instruction each).
> Connect to simple RC lowpass filter and a meter and read off
processor load
> directly (or to a scope if you are looking for exact timing details)!

At had to smile at this because a EE I work with suggested the same
thing.
He suggested it to a room full of programmers ... we all looked at each

other and smiled. And I said, "Well, that's a EE's solution ..."

Thanks!
-larry

This problem usually happens when you set the memory models 'near calls
& data' instead of 'far calls & data'. Check your CCS build
options->compiler->advanced

Larry Martell wrote:

> I don't want to slow down any part of the system by doing this. I
> am also timing some things on the P4 side too. Messages and data are
> being passed back and forth between the P4 and the DSP and if I stop
> and do some calculations it will skew the results.


Humm, OK.
Do you have a spare IO pin? set it high at the start of your time consuming
code then low at the end (probably one instruction each). 
Connect to simple RC lowpass filter and a meter and read off processor load
directly (or to a scope if you are looking for exact timing details)!

However, the code to compute a load average is  not exactly complex and you
should not even notice the extra load. It should be less then a page of
assembler for anything even halfway reasonable. 

Regards, Dan.

glen herrmannsfeldt wrote:
> Tim Wescott wrote:
>
> (snip)
>
> >> I do have a 10,000 element array of structures where the struct
> >> contains
> >> 2 ints. So that would be over 80K right there. Then I had a few
other
> >> globals and statics. I planned to time the code I want to
benchmark
> >> 10,000 times and get an average. But even when I dropped that
array
> >> down to 1,000 it still failed with:
>
> >>>>  error: can't allocate .IDRAM$heap (sz: 00004000 page: 0) in
IDRAM
>
> Isn't it possible to compute the average on the processor
> instead of storing all 10000 values?

I don't want to slow down any part of the system by doing this. I
am also timing some things on the P4 side too. Messages and data are
being passed back and forth between the P4 and the DSP and if I stop
and do some calculations it will skew the results.

Thanks!
-larry

Tim Wescott wrote:

(snip)

>> I do have a 10,000 element array of structures where the struct
>> contains
>> 2 ints. So that would be over 80K right there. Then I had a few other
>> globals and statics. I planned to time the code I want to benchmark
>> 10,000 times and get an average. But even when I dropped that array
>> down to 1,000 it still failed with:

>>>>  error: can't allocate .IDRAM$heap (sz: 00004000 page: 0) in IDRAM

Isn't it possible to compute the average on the processor 
instead of storing all 10000 values?

In the days when computer memories were small, many memory 
efficient algorithms were developed which seem to be going out 
of use.

If you store the sum and sum of squares you can compute mean and 
standard deviation.   If you only have 16 bit arithmetic it will 
take a little work to do a 32 or 48 bit sum, but it shouldn't be 
so hard to do.

-- glen