[Efi332] alternate processors

[bowtievette at aol.com]

>Andrei wrote:
>As for the eTPU, while I was doing the medical gig I kept in contact with
Axiom
>Manufacturing, who make most of the demonstration boards for Freescale,
and I
>had a look at the MCF5235. I thought it made a really nice replacement for
the
>'332 - 2 TPUs, lots of speed, hummana hummana hummana, but WHAT THE
HECK??? the
>second TPU is on the same pins as the ethernet - DOH! Perhaps in the
future when
>I get forced. That would mean putting together another tool chain (I have
>m68k-elf-gcc, Cygwin et. al. working with Eclipse and P&Es debugger) and I
would
>have to figure out how to program the eTPU and if it included a $3K
compiler I'd
>pass.

I have the same reaction to the TPU/ethernet port sharing. I guess they must be thinking that TPU users don't need both. Thats bad enough but its the "e" in the TPU thats the real stinker. It would appear to me that they've added an unnecessary layer to the TPU requiring an expensive proprietary compiler that will likely never become generally available thus adding another barrier for lower volume use. That might not be completely unacceptable, except that the automotive binaries for the eTPU are still not available to even start from or just to evaluate. From a distance, there does not appear to be significantly more functionality in the eTPU than the TPU3 so I'm left wondering where the improvement is. I'll be sticking with the 5xx. If they would add an SCC to it (they won't), it would be almost perfect.

>
>Gunter wrote:
>16x or C16x isn't a TriCore, it is a plain 16bit processor based on a 15+
>year old 16bit core design, with quite some nice peculiarities, e.g.
>fast context switches by exchanging the whole register bank with one
>instruction. It also features different memory models (small, huge,
>etc.), just like back in times of the '286. Development environment is
>either Keil (though support may have ceased since they were bought by
>ARM), or Tasking. There is also a (non-GPL'd) GCC port by HighTec.
>It also has interesting programming instructions, like setting a HW bit
>or clearing it.
>
>However, this is not the Tricore. Tricore processors are named TC11xx. The
>automotive series is TC116x.  They feature DSP instructions, like the
>famous MAC (multiply-add) for digital filter structures, so Infineon
>marketing sells it as a general purpose processor AND a DSP in one
>core. I forgot what they mean with the 3rd core.
>...
>..
>.
>Meanwhile they have developed the core the usual way, like deeper
>pipelines, smaller structures, a wider portfolio of IO, etc.
>
>Tricore has a totally different concept of doing cam/crank decoding and
>ignition/spark timing, than Freescale followed with the 332, MPC5xx,
Coldfire
>or MPC55xx.  AFAIK there is no microcode involved.

Its unclear exactly what processor is being used where in the bigstuff lineup. The bigstuff site shows that processor comparo that talks to the C16X but if you look at their gen4, it does use the Tricore. Regardless, I imagine they both do crank wheel decoding via interrupt handling as opposed to any TPU-like device so that explains the emphasis on processor and interrupt handling speed. I'm curious what total CPU overhead is associated with crank wheel decoding and servicing injection events etc. It appears from the MS site that they are doing crank wheel decoding in a relatively small fraction of total load. That with the MC9S12.
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20070104/fe47b9eb/attachment.html