SPI performance on Freescale MPC83xx?

Hi,

In our project, due to some restrictions and requirements we would have to use the SPI of a Frescale MPC83xx for receiving a continous stream of serial data at a bit rate of at least 500 kbps, but would like to use modes with up to 12 Mbps as well.

As it seems, there is no DMA support for SPI, so we would have to spend CPU time for this (either via interrupts or via kind of polling). Does not look very promising, does it? I expect even with the lower bit rates a very high CPU utilization, which could not be accepted, since other tasks have to be executed as well.

Does anybody have some experience with the performance and ressource consumption of the MPC's SPI? Could you please share your experience and provide some numbers (bit rate versus CPU load)?

Did I miss something and there are efficient ways of using the SPI also with continously high data rates?

Any help appreciated.

Thanks, Matthias

Reply to
Matthias
Loading thread data ...

General response, not knowing the MPC: you might consider using a separate chunk of logic to accept the SPI data into a shift-register (of whatever length: the bit-width of the memory's data bus seems logical), and from there write it to memory. This could either be shared via DMA, or entirely separate and polled. I've done something similar, albeit within an ASIC, and not at this kind of throughput.

Or you might get lucky and find a device that includes the above functionality in a convenient form...

Steve

formatting link

Reply to
Steve at fivetrees

IMHO, the SPI peripheral in the 83xx is a cluster fsck. The documentation is even worse. The documentation was clearly written by someone who does not understand the english language, and appears to not have been proof-read.

As a longtime user of Motorola processors and documentation I have always been very impressed with the quality and consistency of the user manuals (68xxx and 8xx), but the latest round of

83xx and 85xx has been disapointing at best. I let Freescale know what I thought. On top of that their web-based "support" sucks.

Once you get in touch with a *real* FAE, it gets better, but getting there ...

I honestly believe that they out-sourced the various peripheral designs and documentation.

Yeah, no SDMA like we're accoustomed to on the older QUICC platforms.

I have the opposite problem. My SPI peripherals need clock rates that are lower than the 125KHz minimum that I can get with my

128MHz system clock.

You didn't miss anything, though I don't think that SPI was really

*designed* for high speed data comm.
--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Michael N. Moran schrieb:

Thanks for the reply, now at least I am not feeling alone ;-)

What is your CPU utilization with 125kHz SPI (at which CPU clock)?

Thanks, Matthias

Reply to
Matthias

Sorry for the "schrieb" - Googles interface tricked when I was looking in the other direction... Why can I select between several languages (including "German/automatic" whatever this means), but cannot select English - it is just not contained in the drop down list?!?

But back to technical topics...

[/OT]

Regards, Matthias

Reply to
Matthias

I have not done a measurement. Since our SPI traffic is short and bursty rather than continuous, the performance impact is likely in the noise. Our system has a 32MHz oscillator. The system clock is 128MHz and the CPU clock is 384MHz.

BTW, we are running Linux 2.6.17.2 on the prototype. I modified the driver to pause for several hundred microseconds between byte transfers to give the AVR SPI slaves time to load their single "buffered" receiver/transmitter shift register without over/underflow (which is also a design that sucks IMHO.)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Okay, that's what I expected... So we will find out ourselves, for good or worse. ;-)

As Steve pointed out, we could change the HW. If we would decide to go this way, suddenly a wonderful world of new possibilities would open, but for obvious reasons we will try to stick to the existing approach.

Thanks for the help, Matthias

Reply to
Matthias

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.