16 Bit SPI with 16F877A- Is it possible?

[indiansiva555@gmail.com]

Hello Experts,

I am quite new to SPI with PICs.
Please help me out with the basics of SPI communication.

PIC 16F877A datasheet mentions that SPI is for 8bits.

I want to communicate with L9942 Stepper Motor Driver IC whose SPI frame width is 16bit.
Also the datasheet of L9942 Stepper Motor driver IC specifically says the following condition for its Data Input Pin (DI)

Serial data in (DI)
"The input pin is used to transfer data serial into the device. The data applied to the DI will be
sampled at the rising edge of the CLK signal and latched into an internal 16 bit shift register.
The first 3 bit are interpreted as address of the data register. At the rising edge of the CSN
signal the contents of the shift register will be transferred to the selected data register. The
writing to the register is only enabled if exactly 16 bits are transmitted within one
communication frame (i.e. CSN low). If more or less clock pulses are counted within one
frame the complete frame will be ignored. This safety function is implemented to avoid an
activation of the output stages by a wrong communication frame"

Please find the link below for the datasheet:
http://www.st.com/web/en/resource/technical/document/datasheet/CD00072898.pdf

Please help me out if I can interface PIC16F877A with L9942 via SPI by holding the SS pin of SPI for two bytes?

Or else what are the other solutions?

Thanks in Advance

[Ttelmah]

Of course you can.

Key is to understand SPI. Devices using 16bit SPI (or 24bit - some Texas devices), can be driven with 8bit SPI fine. On SPI, the device is 'synchronous', so depends on the clock from the master device. An 8bit SPI master talking to a 16bit SPI slave, just sends two 8bit bytes one after the other.
The sequence is 'drop the CSN line'.
Send byte #1.
Send byte #2.
Raise the CSN.

Now there is a fractional 'pause' in the clock between byte #1, and byte #2, as the PIC SPI buffer is reloaded, but because of the synchronous nature this doesn't matter at all.

The key things are that you must wait for the second byte to send before raising CSN, and must (obviously) get the bytes in the right order (remember SPI is usually MSB first).

Now things to look at are the SPI clock rate (4MHz max), and the modes (sampling is on rising edge, and clock can idle high or low, so Mode1, or mode3 - I'll use 1).

The CCS #use spi, and spi_xfer driver can do this automatically for you.

[indiansiva555@gmail.com]

Thanks for the great response.

[asmboy]

With SPI the clock duty cycle timing can be erratic with no harm.

What matters is that the timing of clock to data is correct.

ie: change data -then toggle clock. and repeat as needed.

SPI frames of ANY bit count can be transferred this way -
and even simple bit-banging works perfectly.

[indiansiva555@gmail.com]

Experts,
Please find program below:

[PCM programmer]

[indiansiva555@gmail.com]

Thank You for your grateful response.
I have changed the mode to MODE0. Still there are issues with SPI communication.

Need to understand more on how this SPI communication works.
Here in my code I am using spi_xfer () function. I have initialized variables for both transferring and receiving.

For my driver IC, I have to send data to 8 registers and each register is of 16 bits.So I have initialized two variables for each registers and sending both one after the other having CSN High.

With spi_xfer (), it also receives the data from the slave (Driver IC in my case) during the falling edge of the clock. But the slave (Driver IC) does not send any data for the first three clock cycles as it is the address. It actually sends the data for the address selected in the data sent to slave (Driver IC).

So,do I have only 5 bits of data received or how it is?
If it is only 5bits of data, how it is stored in the receive buffer?

Also there is a fault bit sent by the slave when both the Clock (CLK) and CSN are low. Will this also be stored in the receive buffer?

I am displaying the received values in an LCD, but they are not the same which I have sent.

Is my SPI programming sequence right in the code?

[Ttelmah]

1) Please learn to use the code buttons......
2) Approach is much more complex than it wants to be.
Just the initialisation, but:

[indiansiva555@gmail.com]

Thank You Experts...
I have changed approach as you suggested by you.
Also I am sending the register value twice which makes it happen.

But reading the register value back from the slave is a problem now for me, because the DI of controller shall receive only 13 bits in return. So how are the values stored in the variable?

Please refer to the attached image link below for the Transfer timing requirement with the slave (L9942 Driver)

[img] https://drive.google.com/file/d/0B-AU2eF393PpRWNnaW8wd3Rodm8/view?usp=sharing [/img]

Should I use any delay between spi_xfer() function and the return value assignment operation?

[Ttelmah]

First, printing. Why waste time and code printing all the bits one by one?.
string=itoa(value,2,string);

converts a value into a binary string. Part of stdlib. It's a standard C function.

Then spend some time actually reading the data sheet. Look at figure 10 'transfer timing diagram'. Note how the chip returns 3 bits shown as 'fault bit', then clocks out 13bits of the value being returned. Since SPI is MSb first, means the register value if the low 13 bits in the value returned.

The data sheet also answers the question about delays: Look at what Tcsn must be. Then think why I have a particular delay between the functions.

Then, CSN, wants to be high when you arrive in the code. This should be part of your chip initialisation at the start of the main. Why are you setting it high when you have finished?. Also why the enormous delays. The load times of registers etc., are in nSec. mSec delays may well cause chip problems leaving parts of it programmed to modes you don't want.

You seem also to be determined to do things as slowly as possible. This risks problems. When programming a chip involving power, you need to be sending the values ASAP, or if it momentarily goes into an invalid setting, you can damage hardware. The whole programming should be done in a few uSeconds, not at 1000bps, with mSec delays. Most such chips do have _minimum_ clock rates. The data sheet has it being programmed at 4MHz, to 5MHz.

Then you are not having to send the data twice. It is programmed the first time you send it, but you need to understand SPI.
When you clock a value 'to' an SPI register, you receive 'back', the value that _was_ in the register. The new value is in there. You are wasting time by sending it a second time. Unless you have no confidence at all in your hardware, you _know_ what you have sent.

The data sheet has the double transfer described, with the comment that if you want to be sure the chip has received the data, clock it to it twice, and then verify what is read back matches what is sent.

Why do you initialise the receive registers?. Since you fill them with a value returned, putting values into them is pointless.

[indiansiva555@gmail.com]

Thank You..

Return value works perfectly with the current program itself, I had not observed it properly. The last 13 bits are actually showing the status of the registers, but only if I write to the slave twice.

I have now changed CSN and reduced timings as suggested which has improved the response time for my direction input.

With change in baud rate, I observe a strange change in smoothness of the motor rotation. As baud rate increases, the motor is not smooth in operation but SPI communication is proper. Why does it happen so? Is it because of improper impedance in the driver IC circuitry?

_________________
-humble request from a beginner