SPI communication

[rob norris]

Hello. I'm in a project where we are trying to make a PIC18F452 talk to a LCD controller chip via an SPI bus. For the last few days i've been getting nothing but random values back from the chip with the SPI_READ() command.

To test out the SPI bus, I disconnected the circuit and am now using two PIC microcontrollers to try to talk to each other, just to verify my SPI communication is working correctly. It turns out I'm having problems with this too.

The test I made is this: the master sends out either 01010101 or 10101010 across the bus. The slave then checks what it has recieved. If it has recieved the first byte i mentioned, it returns 11110000. If it has recieved the second byte I mentioned, it returns 00001111. The problem is, my master pic is reading back 01010101 and 10101010, which are the commands that it sent in the first place! I'm not sure how this is possible but it shows that I am not using the SPI bus correctly. I have the data-in and data-out pins on the pics crossed over and the master generating the clock (sclk) for the slave PIC.

Heres relevant code snipped from the master and slave code:

MASTER:

setup_spi(SPI_MASTER | SPI_H_TO_L | SPI_CLK_DIV_16);
while ( TRUE ){
SPI_WRITE(0b01010101);
xval = SPI_READ();
SPI_WRITE(0b10101010);
yval = SPI_READ();
printf("data: %U, %U\n\r", xval, yval);
delay_ms(200);
}

SLAVE:
setup_spi(SPI_SLAVE);
while(TRUE){
incomingCommand = SPI_READ();

if (incomingCommand = 0b10101010){
SPI_WRITE(0b11110000);
}

if (incomingCommand = 0b01010101){
SPI_WRITE(0b00001111);
}
}

Can anyone find anything wrong with what I am doing? Any help would be tremendously appreciated.. If I can figure out what the problem I'm having between the two PICS, i can probably figure out why the communication to the LCD controller is misbehaving. Thanks!!

[PCM programmer]

[kloppy]

what kind of lcd controller do you use?

i also used an lcd controller with spi and you need to consider a lot of things...

[Ttelmah]

The key' is to remember that SPI talks in both directions _at once_ The byte received from the SPI, when the 'master' sends the first character, is whatever was sitting in the transmit register of the 'slave'. If you want to talk to a slave, and get a reply, you have to send a byte, wait long enough for the slave to have loaded the register, and then clock out another transmission, and then look at the received character. If the response is itself handled by another processor, it can be suprising how long the turnround time needs to be.
So in the case given, talking to a second PIC, this will receive the character, and interrupt at the end of the character. The interrupt latency can be very long (perhaps 30 instructions on a 16 chip, and as much as fifty instructions on a 18chip). Then the slave has to read the character, decide which reply to send, and load this into the output register, which takes perhaps another five instruction times. Only at this point, is the 'reply' ready to retrieve. Given that clocking the character itself, will take perhaps another 8 instruction times (depending on the clock rate selcted for the SPI), the reply will not be available till as much as 70 instruction times after first clocking the data out.
Where SPI is good, is on subsequent transfers. Assuming you send something like a command byte to trigger a particular transfer, you can then send the rest of the bytes at high speed (assuming the slave stays inside the interrupt handler), and accept a transfer back at the same time. For simple 'command/reply' transfers, I2C, is simpler, and nearly as fast.
The supplied CCS routines, are themselves 'irritating', when dealing with the SPI. I use a set of macros instead, which allow lower level access to the seperate parts:

[Charlie U]

You folks will probably all groan when you see me reply to an SPI question again, but I thought that I'd at least lob this over the wall again.

Here is the body of an email that I sent to CCS in Feb. 2002. I sent it again this past summer and they added buttons in the project wizard for the spi clock bits, but they got it wrong again. I have filed another bug report with the following again to try to have them change the buttons to reflect the SPI modes NOT the pic clock bits.

Here's the email:

[Guest]

Sorry. I should have included more information in the original post. The controller I am trying to connect to the PIC via the SPI bus is an LCD touch screen controller, not an LCD driver. Should have clarified that. The chip im using is the MXB7843 made by maxim:

[http://www.maxim-ic.com/quick_view2.cfm?qv_pk=3401]

The way this touch screen controller is supposed to work is you send it a command byte to request the X or Y position of the position being touched on the screen, and then the touch screen should process the command and return the appropriate value.

The touch screen controller requests a clock thats at least 500kHz and at most 2Mhz.. I played around with the DIV, and using "setup_spi(SPI_MASTER | SPI_H_TO_L | SPI_CLK_DIV_16);" appears to give me around 1.1Mhz (says the oscilliscope), which appears to be a good value.

One thing which I'm not sure how to do is:

The manuel for the controller says "CPOL and CPHA = 0".. how do I set these values in CCS C? I read that they mean polarity and phase, but I'm not positive what they are or how to configure these settings.

Any advise would be greatly appreciated.

[rob norris]

that last message was posted my me, the thread started. Forgot to add my name up there.

[Trampas]

Personally when I start interfacing with a new device like an LCD I will often pull out my bit-bang SPI code. This allows me to operate the device really slow while watching the scope/LEDs to make sure the interface is working per the device's spec.

Once I get the device all working using the bit-bang interface I know that the PCB is correct and the device is connected correct. Then I can migrate the bit bang to the hardware SPI/I2C, etc.

This also has saved my butt more than once. For example I have upgraded the compiler and my SPI device stopped working. Now I had to determine if the problem was compiler, or the device I was working on. Thus by enabling the bit bang interface, I knew problem was compiler.

I know it sounds like a lot of work to make bit bang when there is hardware on the chip, but trust me it will save you time.

Trampas

[rob norris]

I figured out how to set CPOL and CPHA from Charlies reply. Both are set to 0 now by changing the SSPSTAT and SSPCON1 registers. I'm still having the same problem though, in getting values back from the touch screen controller... The touch screen controller is reading back 51,58 for the x,y coordinates now.. and give these values in all situations (whether your touching the screen anywhere or not)..

Does anyone have any further suggestions? It appears the timing and setup of the ssp bus is correct (to me)...

:(