16F877A spi uses 8-bit, I need 16

[dbaltz]

I have a 16F877A and am trying to use spi to set up a MCP6S22 PGA which requires an uninterrupted 16-bit SCLK. Everything I have tried inserts a SCLK delay between the high and low bytes. The documentation suggests that 16-bit words are possible using the FORCE_HW mode. Has anyone done 16-bit spi mode without a SCLK delay after 8 bits? I just need to do a few bytes of setup so clock rate is not a concern.

[PCM programmer]

Don't use the #use spi() library. Use the setup_spi() function to setup
the SPI mode and speed. Then use spi_write() two consecutive times
to send two bytes. Make sure you connect your device to the hardware
spi pins on the PIC.

Look at the w5100_write_reg() routine in this code:
http://www.ccsinfo.com/forum/viewtopic.php?t=40693&start=10
Notice how several consecutive bytes are written to the slave device
with spi_write() statements.

You need to write your own routine(s) in a similar way, to make a
driver for the mcp6s22. Study the SPI bit diagrams in the mcp6s22
data sheet and make your routines conform to those diagrams.

[dbaltz]

That is basically what I did however looking at the SCLK on a scope, there is a delay between the 8 cycles of the first byte and the second. The MCP6S22 timing diagrams (and the text) say that the SCK must be continuous for 16 cycles.

[dbaltz]

I did try using the setup_spi() call instead of the #USE SPI with no improvement.
One note: I am using a slow (1MHz) clock. Could that be the issue? Interrupt latency?

[PCM programmer]

In the general case, the 16 bits of the transmitted SPI word do not have
to be transmitted at the exactly the same interval. You're allowed to
have a gap between the two bytes.

[dbaltz]

That's good to know. Perhaps the MCP6S22 spec is overly restrictive and my problem is elsewhere.

[PCM programmer]

Post your driver code and a small, complete, compilable test program
that calls the driver. Explain how it fails.

[FvM]

[John P]

I agree with what others have said--I'm very skeptical that the component requires an absolutely regular clock for a 16-bit SPI input. Especially as there's apparently no spec for what the frequency needs to be!

But anyway, if you want an absolutely regular clock and you're prepared to accept a slow sending rate, you can always forget the built-in SPI routines and just simulate the whole thing with a timer interrupt and bit-banging, and nothing prevents you from using the "normal" SPI pins to communicate with. I don't think it's likely to change anything. But you can do it.

[dbaltz]

From Section 5.1 of the MCP spec:

"There must be multiples of 16 clocks (SCK) while CS is low or commands will abort (see Section 5.3, “Registers”)."

And from my code:

[Ttelmah]

The 8bit SPI, is fine for what they say.
The 'point' is that the chip must _always_ receive 16 clocks, between the CS going low, and the CS rising. This is common. However the clocks do _not_ need to be the same length.
Some comments:
1) Why do you drop and raise the CS twice. Not necessary.
2) Check the data sheet. Is there a specification for how much time is needed between CS dropping and the first clock. It is common for a small delay to be needed. You may have added the second operation on the line becaue of this?.
3) Your main problem, is that you are not waiting for the SPI to send the data before raising CS. This would violate the data sheet requirement.
The SPI hardware, will still be sending the last byte.
For the transmssion, use a _read_:

[FvM]

After you finally revealed your code, there is at least one trivial problem (I guess, there aren't more):
MCP6S22 is specifying SPI mode 0 or 3 while you are using mode 1. Correct this and try again.

[dbaltz]

Setting the SPI mode to 1,1 was the fix. All is working now. Thanks.

The PIC16 does indeed finish the spi_write(). There was no need to add delays or an spi_read().