CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
SPI data only partially good
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
bas



Joined: 30 Jan 2005
Posts: 4

View user's profile Send private message Send e-mail

Yes, but....
PostPosted: Sun Jan 30, 2005 6:27 pm     Reply with quote
We have a total of three 18F452's involved now--the main (master SPI), the audio (slave SPI), and the simulator on the breadboard (slave SPI). All three are running at 24 MHz.

The audio PIC's slave SPU port is set up as Jeff said

setup_spi (SPI_SLAVE | SPI_H_TO_L | SPI_XMIT_L_TO_H);

and it works with no problem.

But, in any matter, it seems to me that if the master and slave or both L_TO_H or H_TO_L, the problem will be the same. Doesn't one transition (say, H_TO_L) need to tell the slave to put the data bit to the output pin, and the next transition (in this case, L_TO_H) tell the master to latch that data bit? In other words, the slave puts on the falling edge and the master samples on the rising edge?

I guess I am unclear on the difference between SPI_ and SPI_XMIT in this case.

I don't think the PIC is resetting, Gary. MCLR is tied high with about a 20k resistor. We learned that after the 16C745 episode....

We're not using the RJ11 to connect the breadboard to the prototype board, but we're using connectors so we're sure contact is good, and the total wire distance is about 8" or so.
bas



Joined: 30 Jan 2005
Posts: 4

View user's profile Send private message Send e-mail

Loading problem
PostPosted: Sun Jan 30, 2005 8:07 pm     Reply with quote
Oh yeah--

With respect to loading with the scope, we're not always probing it, and we see the same results whether we're probing or not.

I've found that we usually don't have a problem as long as we use a probe with a 10x setting, which increases the input impedance of the probe to a level that a PIC GPIO can drive with no problem, even at pretty high frequencies.

That problem has tripped me up in the past, though. For example, it's almost impossible to measure the oscillator on a PIC by probing with a 1x probe. The capacitance is so large that is loads the oscillator and destabilizes it so that it no longer runs. We found that one out the hard way!
Neutone



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

Re: SPI data only partially good
PostPosted: Mon Jan 31, 2005 10:11 am     Reply with quote
object01 wrote:
The master executes,

Code:
array[x] = spi_read(0b10101010);   // dummy data for scoping


in groups of three. Before a read, we set SS low, and after each read, we set SS high. After a low-read-high operation, there is a delay of 1ms.
Jeff S.


I wrote some code that runs full duplex between PIC's.
Have a look at this link.

http://www.ccsinfo.com/forum/viewtopic.php?t=2676&highlight=spi
object01



Joined: 13 May 2004
Posts: 90
Location: Nashville, TN

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Jan 31, 2005 10:13 am     Reply with quote
If the following statement,

Code:
spi_setup(SPI_MASTER, SPI_H_TO_L, SPI_XMIT_L_TO_H);


sets up an SPI master to transmit on the rising edge, then we can conclude that it receives on the falling edge.

If the slave uses,

Code:
spi_setup(SPI_SLAVE, SPI_H_TO_L, SPI_XMIT_L_TO_H);


then it is also transmitting on the rising edge and receiving on the falling edge.

Therefore, the master is transmitting on the rising edge, and the slave is receiving on the falling edge.

Now, what if the slave is chip selected while SCK is high? At first glance, it seems to me like the slave will sample the first bit before the master transmits it.

Is the device smart enough to know to wait for the defined SCK idle state before shifting bits in?

--
Jeff S.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Mon Jan 31, 2005 2:54 pm     Reply with quote
Quote:
If the following statement,

Code:
spi_setup(SPI_MASTER, SPI_H_TO_L, SPI_XMIT_L_TO_H);


sets up an SPI master to transmit on the rising edge, then we can conclude that it receives on the falling edge.
Your conclusion is wrong, SPI is working in a different way. Both the master and slave will start transmitting data in the first half clock period, then on the second clock edge both parties will latch the data on the bus. It's not like the slave waiting for the master or something like that, but both transmitting simultaneously. In your setup the non-active level is a high level and data is clocked-in at the rising edge.

Like I said before, have a good look at the 'SPI MODE WAVEFORM (MASTER MODE)' figure in the PIC-processor manual, it's all in there. I pointed to figure 17-3 in the PIC18F458 manual, for your PIC18F452 that's figure 15-3.
bas



Joined: 30 Jan 2005
Posts: 4

View user's profile Send private message Send e-mail

PROBLEM SOLVED
PostPosted: Tue Feb 01, 2005 9:59 pm     Reply with quote
Okay, we figured out the problem. It turns out the solution was buried in the Errata document of the 18f252:

Quote:
10. Module: MSSP (SPI, Slave Mode)
In its current implementation, the SS (Slave
Select) control signal, generated by an external
master processor, may not be successfully recognized
by the PIC® microcontroller operating in
Slave Select mode (SSPM3:SSPM0 = 0100). In
particular, it has been observed that faster
transitions (those with shorter fall times) are more
likely to be missed than than slower transitions.
Work around
Insert a series resistor between the source of the
SS signal and the corresponding SS input line of
the microcontroller. The value of the resistor is
dependent on both the application system’s
characteristics and process variations between
microcontrollers. Experimentation and thorough
testing is encouraged.
This is a recommended solution. Others may exist.


We used a 100 ohm resistor in series with the SCK line. It worked right off the bat...
Guest
Re: Yes, but....
PostPosted: Thu Oct 06, 2005 9:10 am     Reply with quote
bas wrote:
We have a total of three 18F452's involved now--the main (master SPI), the audio (slave SPI), and the simulator on the breadboard (slave SPI). All three are running at 24 MHz.

The audio PIC's slave SPU port is set up as Jeff said

setup_spi (SPI_SLAVE | SPI_H_TO_L | SPI_XMIT_L_TO_H);

and it works with no problem.

But, in any matter, it seems to me that if the master and slave or both L_TO_H or H_TO_L, the problem will be the same. Doesn't one transition (say, H_TO_L) need to tell the slave to put the data bit to the output pin, and the next transition (in this case, L_TO_H) tell the master to latch that data bit? In other words, the slave puts on the falling edge and the master samples on the rising edge?

I guess I am unclear on the difference between SPI_ and SPI_XMIT in this case.

I don't think the PIC is resetting, Gary. MCLR is tied high with about a 20k resistor. We learned that after the 16C745 episode....

We're not using the RJ11 to connect the breadboard to the prototype board, but we're using connectors so we're sure contact is good, and the total wire distance is about 8" or so.
Guest
PostPosted: Fri Dec 02, 2005 8:16 am     Reply with quote
object01 wrote:
Both PICs are running at 24MHz.

--
Jeff S.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group