“Miguel Simon” <simon@ou.edu> wrote in message
news:3B29A460.E4859400@ou.edu…
Igor…
Ok, I see it now; somehow I did not see this before. As you say, the
MPC555 and the MPC823e complement each other -they can interface via
QSPI for example, and in this way you have the whole machine in two
parts. Each one part does what it is suppose to do with no necessary
overlap.
As a matter of fact, this fit a set of robotic models very nicely.
Yes, it’s a sweet combo. The 555 takes care about analog I/O like
sensors/actuators, while 823e handles imaging/communications.
I’ve
been doing the same sort of thing between an intel CPU (PC104 form
factor) and a set of two MC68332. In theory I can use the MPC823e in
place of the intel CPU and the MPC555 in place of the two 332’s. When
the whole thing is done I’ll save about 2lb of hardware -a significant
percent of the aerial robot take-off gross weight- for a reasonable cost
penalty. Nice indeed. > 
Going back to the original post, now I understand why Nto will not run
on a MPC555, but it would be nice if it did any way. > 
> Reminds me of
the cartoon-like story of the Bumble Bee which -after wind tunnel tests
and all- engineers concluded that could not fly, but flew any way
because the bee did not understand the engineers! Too bad that the
MPC555 is not a Bumble Bee…, but QSSL engineers are very smart any
way, unlike all those other engineers! > 
By now I think the rationale behind decision to not put MMU on the 555 was
speed. Keep in mind, it is only 40Mhz (56Mhz for 565). The whole virtual
addressing enchilada with BAT/PTE/TLB adds considerable overhead and does
not fly well on 40Mhz (plus it drains power and increases power
dissipation). To make it much faster than that was probably rather hard at
the time (1998), considering required temperatures range. So they decided to
save on MMU expenses, which seems reasonable considering what kind of
applications will run on this baby. The 555 has so much specialized hardware
on chip, it is practically a ‘generalized ASIC’, targeted to very particular
market. It is rather unlikely that someone will want to run general
applications mix on it, so considerations of memory protection become
secondary. The speed and reliability are primary because the baby is driving
your powertrain. Most likely there will be just one application consisting
of single control/communication loop. Such application would not care (or
use) much of sophisticated OS features, it would rather care about meeting
deadlines and being able to talk to hardware.
Which leads to reasonable idea to use as RTOS with simpler memory model,
which Motorola supplies (RTEK) along with low level driver library providing
API to talk to I/O modules. Even if QNX was to support this chip, they
probably would not want to reimplement the driver library, so they’d had to
use a memory model compatible with it, which I suspect precludes memory
protection at all. It would have to be a single process model with
everything linked to kernel/libc. Hey QNX, may be it is time to reanimate
NTO 1.0 All you’d need to do is procnto+libc+flash+communication/debug
module. Plus linker and availability of driver library
Ok, where are we going with this? If you’re going to use that little of OS
features, do you really care what OS is it? One could as well stick with
RTEK on 555 side and use NTO on 823 side.
Thanks again.
Bests…
Miguel.
Igor Kovalenko wrote:
As I see it, MPC555 and MCP823e are complementing each other, rather
than
competing. The MPC555 was designed specifically for engine/transmission
control systems. Having slow CPU frequency it however can operate in
very
harsh environment - from -40C to +125C and has lot of flash memory
(500K).
Since all I/O controllers are on chip and flash can hold whole OS and
applications, you don’t have to worry about environmental capabilities
of
external chips which you would need otherwise. You can house it right on
the
engine. Try to find equivalent components with similar temperature range
for
reasonable price, good luck. Last time I checked, anything what works
above
+30C costs you a small fortune if available at all.
Besides there’s software support for it (engine/transmission control
software) from leading vendors, which already exists and makes use of
all
its built-in goodies. One of vendors even collaborated with Motorola to
design new version (MPC565) which has higher frequency, 1Mb flash, 3 CAN
controllers and automotive-industry-standard debug/calibration port.
Unfortunately it still has the same ‘MMU’ as 555, to maintain
compatibility.
I very much doubt that all will be scrapped just because some other CPU
has
MMU…
OTOH, the MPC823e is much more oriented to automotive
navigation/communication/entertainment systems. It has no I/O modules
suitable for engine/transmission interfaces, but has USB, video, LCD,
serial, ethernet etc. It is faster but can’t sustain temperatures like
555/565.
Now, I don’t know if MobileGT project involves powertrain applications
or
not. I had impression it is mostly related to
navigation/communications/entertainment, where 823e is really good,
which is
why it is going to be the reference platform. But Armin might know
otherwise, since he’s involved with CAN support in MobileGT. May be
scope of
the project expanded with time >
“Miguel Simon” <> simon@ou.edu> > wrote in message
news:> 3B2967AB.88AF7F75@ou.edu> …
Armin…
Armin Steinhoff wrote:
Nice so far … but AFAIK the MPC555 will be the base of the
MobileGT product line, that means the
MPC555 has the potential to kick QSSL out of the MobileGT business
How do you know that this is the case? In any case, what development
environment do MobileGT folks use if they do use the MPC555?
In the link > http://www.qnx.com/news/tpnews/jun05_01-mbgt.html > it says
that:
“The Motorola mobileGT MPC823e Standard Development Platform utilizing
QNX OS, IBM (OTI) Java, and eNGENUITY technologies will be available
from Metrowerks in the third quarter of 2001.”
I suppose that in the above quote “…third quarter…” refers to the
June 6.1 release, right? Regardless, currently we are using MPC823e
as
well, but this processor has limitations wrt IO needs.
Regards…
Miguel
Armin
\
my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com