Searching \ for '[PIC] SPI Clock' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=spi
Search entire site for: 'SPI Clock'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] SPI Clock'
2007\05\26@232943 by Ira Burton

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

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.  I need to make sure this would be reliable in the
real world.

Any thoughts?

2007\05\27@020244 by Robert Rolf

picon face
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


2007\05\29@154440 by Andre Abelian

flavicon
face
Sure,

Last 3 weeks I was working with SPI interface to communicate with
external ADC and co processor. What I noticed that each device has
it's own requirement. Some of them speed doesn't matter and some will
give you a limit so to answer to your question depending on what chip
are you going to talk to may require different setup like clock out @
falling edge and data in on rising edge etc.

Andre



{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...