Ira Burton wrote:
> I asked this question once before in a slightly modified manner and never
> received a response so I thought I would try again.
> 
> I have two PIC processors running at different speeds.  One is running at
> 8MHz using the internal clock and another is running at 40MHz (via PLL).  My
> question is if I use the faster PIC as the master can I reliably send data
> to the slower as long as I don't exceed the slower processors processing
> capability.

Since the 'master' is responsible for clocking in the data, as long as the
'slave' can process the byte before the next incoming byte is completely shifted
in, you should be OK. (constrained by the maximum clock rate for the slave).

> I have built a simple test circuit that appears to work, but I want to make
> sure that it is "within spec."  I cannot find reference to this in any data
> sheet or other document.

You won't find this because it's not a 'spec'. It's away of using the device.
As long as your constraints are met (don't clock faster than the slow speed allows,
read the byte before the next one completes shifting), you will be fine.
See table "SPI Mode Requirement" in the specs. Many of the setup times are
in terms of Tcy of the slave device, so you have to make sure the master
meets them. i.e. SCK input high and low times are Tcy + 20 ns so your max
allowed clock rate is 1/[((4/8Mhz)+20ns)*2] = 960 khz. Plus margin for xtal
rate errors.

>  I need to make sure this would be reliable in the
> real world.
> 
> Any thoughts?

Think it through.
How fast are you clocking? How long does it take to shift out a byte?
How much work (time) does the slave have to do to
move the received byte out of the SSPBUF and be ready for the next byte?
As long as you have sufficient margin (one bytes clocking time at least) you should
be just fine.

The SPI is only SINGLE buffered. You MUST get the data byte out of SSPBUF
before the final clock cycle happens or you'll overwrite the contents.
There is a flag in SSPCON to detect this (SSPOV), so your software can
confirm that you've never overrun your processing capacity.

Robert


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist