PIC24 to PIC24 SPI

[rkrishnan]

Hi,

I am new to the C environment with PICs and PIC24, but not with PICs,
MPLLAB & Assembly. Iw as planning to buy the book but first wanted to
check if the documentation fully covers all .c & .h files in the
library.

I really like the generous supply of comprehensive libraries and I
must compliment you on making this avialable to all.

I was trying the SPI examples in Chap10, and saw some materials for
wiring teh Dallas temperature sensor. Since I don't have one, but do
have a PicBully and an extra 'GP202 on a breadboard. I tried to get
the SPI routines (spi_master_revstring.c and spi_slave_revstring.c)
in Chap 10 that connect two PIC24HJ32GP202's. I have everything wired
up correctly, with the proper code in the master and the slave PICs,
but even though the slave is sending a nice pulse back after receiving
a 63 byte string (confirmed by scoping) at SLAVE_ORDY , the master
never detects this.

I have not given up yet, (that's part of the fun!) but would like to
know if this code has been tested ?

I have wired it like this:

Master PIN
Slave PIN
SDO1 RP6 15 SDI1
RP5 14
SCK1OUT RP7 16 SCK1OUT
RP7 16
SDI1 RP5 16 SDO1
RP6 15
SLAVE_ORDY RB2 6 SLAVE_ORDY
RB2 6
SLAVE_ENABLE RB3 7 SS1IN
RP3 7

Any help or pointers would be appreciated.

Thank You

[rbre...@gmail.com]

Yep, all of the code has been tested. That is how I got the nice logic
analyzer shot in Figure 10.39.
Let me see if I can reconstruct the connections as in your email/
book:

Master Pin Slave Pin

SDO1 RP6 15 SDI1 RP5
14
SCK1OUT RP7 16 SCK1OUT RP7 16

SDI1 RP5 14 SDO1 RP6

15
SLAVE_ORDY RB2 6 SLAVE_ORDY RB2
6
SLAVE_ENABLE RB3 7 SS1IN RP3 7

Yes, those are the correct connections.

First, try sending a short string, like 'heck', or something like
that, only use four characters so that you can ensure the input UART
is not getting overrun for some reason (even though an error message
should be printed if this occurs).

Once the string is sent by the Master and received by the slave, the
master negates the SLAVE_ENABLE line (makes it high). The slave will
then assert the the SLAVE_ORDY line (make it high) after the string is
reversed. The master will then assert SLAVE_ENABLE (make it low),
read the reverse string via the SPI bus. When the last character is
read from the slave, the slave will negate SLAVE_ORDY (make it low),
and the master will negate SLAVE_ENABLE (make it high).

If the slave is sending a high true pulse on SLAVE_ORDY, then this
seems to indicate that the master is reading the entire reversed
string back from Slave; but I assume you are not seeing this on appear
on your console output.

Does the console appear to lock up after you input the 64-byte
string?
What console program are you using?

I assume you are using the code 'as is' from the code archive.

[rbre...@gmail.com]

Well, I did find a problem. Somehow the statement

CONFIG_SLAVE_ORDY() ;

got deleted from the configSPI1() function of the
spi_master_revstring.c .
This means the input port of the master for the ready signal from the
SPI is
not being configured.

Add this and see if this fixes your problem.

[rbre...@gmail.com]

OK, there are TWO problems:

a. In spi_master_revstring.c, add the statement:

CONFIG_SLAVE_ORDY();

to the configSPI() function. This line is actually in the book figure
that discusses this function, but during some code reshuffling it got
deleted from the function in the archive.

b. In spi_slave_revstring.c, add the statement:

CONFIG_RB3_AS_DIG_INPUT();

to the configSPI() function. This is the pin assigned to the Slave
Select input (SS1). After the initial version of the code was tested,
some pins got moved around, and the previous pin used for the Slave
Select input was a digital pin. However, it got moved to RB3, which is
an Analog pin, and so the analog functionality has to be disabled by
the 'CONFIG_RB3_AS_DIG_INPUT()' statement.

So, now I have it working again on my local board here. I will update
the code archive tommorrow.

[rbre...@gmail.com]

The code archive has been updated with the fixes. Sorry about the
broken code, I had moved pins around on examples to be compatible with
a PCB we made, but that particular example was not retested. Thanks
for notifying us.