SPI Communication

[HOUDAGHO]

Hello to all, I would like to carry out a project whose principle is the following:
we have two PIC 16F88 microcontrollers, the first peak is the master allows to read the temperature on an LM35 sensor and send it to the other peak which is the slave and the latter which allows to send the sun temperature an LCD.
I tried several times, but no solution succeeded

master :

sbit swcw at PORTB.b0;
sbit swcw_direction at TRISB.b0;

sbit swccw at PORTA.b0;
sbit swccw_direction at TRISA.b0;

//outputs
sbit sck at PORTB.b3;
sbit sck_direction at TRISB.b3;

//outputs
sbit dt at PORTB.b5;
sbit dt_direction at TRISB.b5;

//constants
const char motorcw=0x01;
const char motorccw=0x02;
const char motoridle=0x03;

unsigned int a;
char temp[7];

void main() {
TRISB = 0x00; PORTB = 0x00;
ADC_Init();
//initialization
ANSEL=0x00;
swccw=0;
swcw_direction=1;

swccw=0;
swccw_direction=1;

//Configure MSSP 3 registers
SSPSTAT.SMP=1;
SSPSTAT.CKE=0;
SSPCON.WCOL=0;
SSPCON.SSPOV=0;
SSPCON.SSPM3=0;
SSPCON.SSPM2=0;
SSPCON.SSPM1=0;
SSPCON.SSPM0=0;
SSPCON.SSPEN=1;

sck=0;
sck_direction=0;

dt=0;
dt_direction=0;

TRISB.RB4=0;
Delay_ms(50);
while(1); {
 a = ADC_Read(0);
 a = a*5/1023;
 inttostr(a,temp);
 }
 }

slave

sbit sck at PORTB.b3;
sbit sck_direction at TRISB.b4;

sbit dt at PORTB.b4;
sbit dt_direction at TRISB.b4;


//outputs
sbit mcw at PORTB.b5;
sbit mcw_direction at TRISB.b5;

sbit mccw at PORTB.b7;
sbit mccw_direction at TRISB.b7;

//variables
char rcdata;

//constants
const char motorcw=0x01;
const char motorccw=0x02;
const char motoridle=0x03;

// LCD module connections
sbit LCD_RS at RB0_bit;
sbit LCD_EN at RB1_bit;
sbit LCD_D4 at RB2_bit;
sbit LCD_D5 at RB3_bit;
sbit LCD_D6 at RB4_bit;
sbit LCD_D7 at RB5_bit;

sbit LCD_RS_Direction at TRISB0_bit;
sbit LCD_EN_Direction at TRISB1_bit;
sbit LCD_D4_Direction at TRISB2_bit;
sbit LCD_D5_Direction at TRISB3_bit;
sbit LCD_D6_Direction at TRISB4_bit;
sbit LCD_D7_Direction at TRISB5_bit;
// End LCD module connections

void main() {
lcd_init ();
lcd_cmd(_lcd_cursor_off);
//initialization
ANSEL=0x00;

//Configure MSSP 3 registers
SSPSTAT.SMP=1;
SSPSTAT.CKE=0;
SSPCON.WCOL=0;
SSPCON.SSPOV=0;
SSPCON.SSPM3=0;
SSPCON.SSPM2=1;
SSPCON.SSPM1=0;
SSPCON.SSPM0=1;
SSPCON.SSPEN=1;

sck=0;
sck_direction=1;

dt=0;
dt_direction=1;

mcw=0;
mcw_direction=0;

mccw=0;
mccw_direction=0;
Delay_ms(50);
while (1){
lcd_out(1,1,"khadija");
lcd_out(2,1,"Houda & zohra");
delay_ms(500);
lcd_cmd(_lcd_clear);
delay_ms(500);
rcdata=SSPBUF;
switch (rcdata){
case motorcw:
mcw=1;
mccw=0;
break;
case motorccw:
mcw=0;
mccw=1;
break;
case motoridle:
mcw=0;
mccw=0;
break;
}
}
}

[moderator action: added code tags]

 

[barry]

So, we know what you want to do. What's your problem? Don't just tell us "it doesn't work." Does it burst into flames? Does it shake violently and fall off the table? Does it cause all the dogs in the neighborhood to howl?

The PIC (not "peak") has a debug port; have you tried any debugging? Have you looked at signals with an oscilloscope? Have you programmed the device properly? Have you turned on the power?

 

[Aussie Susan]

There are a number of things wrong with your code that I can see. However some of those might be due to the OP not posting the code originally within the 'code' tags so I would strongly suggest that the OP check to make sure they code is as they have it.
First off is a design issue: I would strongly recommend that you use the \SS\ pin for the salve and drive this accordingly from the master. This will prevent any stray transition on the SCK from completely messing up all further exchanges.
Secondly, both the master and the slave have CKP and CKE as 0. Look carefully at Figures 10-2 and 10-3 and I think you will see that you need to set SMP to 0. If it is set to 1 (as you have it) then you will be sampling right at the time the data is transitioning from one bit to the next.
I can see where you set the SCK pin to be an input for the 'slave' but there is nothing that sets the SCK pin to be an output for the 'master'. (There does seem to be duplicated code where you set the 'swccw' value twice.) Remember the default for the TRISx registers is to set the pin to be an input. Further I can;t see code where you set the SDO pin to output in either apps.
In your 'master' code I can't see where you actually write to the SPI buffer. That is what is required to start the exchange.
In the 'slave' code you don't wait to check that you have received anything from the 'master' but just grab whatever is in the SSPBUF every time. (Don't rely on delays as you can easily get the master and the slave out of sync with each other.) At best you will get whatever was exchanged from the master last time and at worst you will get random garbage. You need to wait for the BF bit to be set before you read from the buffer.
Also you seem to be using the SPI module as a UART where the master simply sends off something and the slave is expected to receive it. That is (almost) how a UART works but not how the SPI module works. The SPI is an *exchange* protocol where the save puts a value into the SSPBUF and then waits for the master to initiate the exchange. When the master write to its SSPBUF, the master and slave exchange their values (with the master driving the clock and therefore the speed of the exchange) and both then set their BF bit high when the exchange completes. At that point BOTH the master and the slave are expected to read the SSPBUF (which resets the BF bit) - if the slave doesn't read the buffer by the time the next exchange occurs, then the SSPOV bit will be set and slave will ignore all further exchanges until it is cleared by your software.
Given all that, as @barry says, we don;t know what your actual problem is. However I suspect that you have not even got anything passed from the master to the slave because of all of the above issues. Therefore they may well be other problems with your code that you have yet to find.
Susan

 

[KlausST]

Hi

things wrong with your code

SPI is quite a standard interface. Thus there is a lot of documentation, tutorials, videos, code examples available.
I´m sure the manufacturer provides al lot of informations.

I strongly recommend to uses these informations.

Klaus