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

"Matthias" <news@ingbh.de> wrote in message 
news:1155573719.290656.163370@75g2000cwc.googlegroups.com...
> 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?

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
http://www.fivetrees.com 

Matthias wrote:
> 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?

<rant>
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.
</rant>

> 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.

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

> 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)?

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.

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

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
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Michael N. Moran schrieb:

> > 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)?
>
> 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.


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

[OT]

Matthias wrote:

> Michael N. Moran schrieb:

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

Matthias wrote:
> Michael N. Moran :
> 
>>>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)?
>>
>>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.
> 
> Thanks for the reply, now at least I am not feeling alone ;-)
> 
> What is your CPU utilization with 125kHz SPI (at which CPU clock)?

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
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Michael N. Moran wrote:
> Matthias wrote:
> > What is your CPU utilization with 125kHz SPI (at which CPU clock)?
>
> 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.


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