Re: Re: performance of the MPC55XX compared to a TI67XX

Julian,

We run from internal RAM because we are currently implementing on a TI 
processor, we load from external flash since there is no internal flash 
and the IO to load from external flash is much more expensive.  That's why 
we're looking at the MPC product.

The question on the speed of the MPC family was kind of a tip of the 
iceberg question regarding the whole of what we're doing.  We have plenty 
of history with partial OS implementations to know we don't want an OS.

Again, thanks for the thoughts, they have been helpful.  Hopefully we're 
on the right track.

Todd




"Julian Requejo" <[email protected]> 
Sent by: [email protected]
01/17/2007 04:10 PM
Please respond to
[email protected]


To
[email protected]
cc

Subject
Re: [MPC500] Re: performance of the MPC55XX compared to a TI67XX









Hi Todd,

May I ask why do you run from internal RAM? I mean, first, you need to 
store the code in flash so you must be copying to RAM and reallocating it 
before running. I believe that some processors like the MPC families are 
designed to run from internal flash in one instruction/cycle so you don't 
gain anything by running from internal RAM. Maybe some people with more 
knowledge on this can comment, I know it depends a lot on what you do 
since the internal RAM goes through a different bus than internal flash. 
There are some technicalities about this, and if I remember correctly, in 
some cases in the MPC555 for example, that some instructions run slower 
from internal RAM than from internal flash. I can't comment on TI.
If you are required to run on dsps, keep in mind that the MPC family is 
not a dsp family. There is a lot of overlap between dsp and micros, but 
the optimizations play a role.

Regarding the OS, think about it. If your app is so simple that you don't 
need an OS, then no OS is a good alternative. Sometimes simple schedulers 
do the job as well. Maybe your requirements don't permit an OS. But my 
point is, think about it. An OS gives your application a solid framework 
to run on, and there are some excellent products out there. They make sure 
your app runs in real-time and that exceptions get handled properly. 
Nevertheless, in many cases no OS is indeed the best choice.

As George said, don't ignore the startup effort. Getting a CPU running 
from scratch takes lots of time. Learning to configure the CPU and writing 
the startup code alone has a learning curve.

I agree with your final conclusion: spend some time testing them hands on. 
This means not just the CPU, but also the quality of the documentation 
(crucial), the tools, support, and performance.

Best luck,
-Julian

 


[Non-text portions of this message have been removed]