 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
 Posted: Sun Jan 30, 2005 5:59 pm |
 |
|
| Quote: | | OK, we'll try XMIT_H_TO_L on both the master and the slave. But what does XMIT_H_TO_L actually do differently than SPI_H_TO_L? I can't find any documentation on it anywhere, including my most recent readme.txt. |
Documentation can be found in your PIC manual, for example figure 17-3 for the 18F458 is very helpful. I guess changing the suggested parameter won't solve your problem. I guess your problem is caused by the SPI_SAMPLE_AT_END parameter which is a Microchip extension to the Motorola SPI combinations.
Just remember, there are 4 general spi setting combinations. Motorola numbers these just 0 to 3 but Microchip and CCS use different names for the same settings. Very confusing, that's why I always use the following table:
| Code: | // Added SPI Mode define because CCS and Microchip made a very confusing mess of it.
// MOTOROLA MICROCHIP CCS
//---------------------------------------------------------------------------------
// SPI Mode 0,0 == CKP = 0, CKE = 1 == SPI_L_TO_H | SPI_XMIT_L_TO_H
// SPI Mode 0,1 == CKP = 0, CKE = 0 == SPI_L_TO_H
// SPI Mode 1,0 == CKP = 1, CKE = 1 == SPI_H_TO_L
// SPI Mode 1,1 == CKP = 1, CKE = 0 == SPI_H_TO_L | SPI_XMIT_L_TO_H |
Most SPI devices can communicate with each other when using the same SPI-mode settings. I don't think one mode is better than another but is dictated by the external devices. Most simple hardware devices only support 1 or 2 modes.
The PIC processors are even more versatile by offering a third parameter 'Input Sample' or 'SMP', extending the number of possible configurations to 8. In CCS this parameter is called SPI_SAMPLE_AT_END. Note that this parameter only can be used for SPI-masters and must be cleared in slave-mode. Hardware behavior for setting this bit in a slave is not defined. For Motorola compatible SPI the SPI_SAMPLE_AT_END parameter should never be set either. |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
|
bas
Joined: 30 Jan 2005
Posts: 4
|
| Yes, but.... |
| Posted: Sun Jan 30, 2005 6:27 pm |
|
|
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
|
| Loading problem |
| Posted: Sun Jan 30, 2005 8:07 pm |
|
|
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
|
| Re: SPI data only partially good |
| Posted: Mon Jan 31, 2005 10:11 am |
|
|
| 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
|
|
| Posted: Mon Jan 31, 2005 10:13 am |
|
|
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
|
|
| Posted: Mon Jan 31, 2005 2:54 pm |
|
|
| 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
|
| PROBLEM SOLVED |
| Posted: Tue Feb 01, 2005 9:59 pm |
|
|
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.... |
| Posted: Thu Oct 06, 2005 9:10 am |
|
|
| 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
|
|
| Posted: Fri Dec 02, 2005 8:16 am |
|
|
| object01 wrote: | Both PICs are running at 24MHz.
--
Jeff S. |
|
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
