Differences between software SPI and hardware SPI

[rfjhh]

Hi

I have a doubt:

What's the difference between using #USE SPI and don't using it?

[PCM programmer]

setup_spi() is hardware only, and is limited to the width of the SPI
hardware buffer (usually 8 bits).
#use spi() is hardware or software SPI, with many options.

[temtronic]

Also remember that a software SPI won't give you an interrupt .
I've gone to a 'bigger' PIC just to get 2 HW UARTS and 2 HW MSSP peripherals for that reason.

Jay

[Ttelmah]

However as a 'plus', the software SPI will (depending on the pins chosen),
possibly have TTL input thresholds versus the Schottky thresholds on the
hardware port. For some devices this can allow operation with peripherals
that can't meet the higher input thresholds.

[Ttelmah]

Given the occasions where people don't understand the CCS abilities, let's
give a fairly comprehensive explanation:

#USE SPI can setup either software or hardware SPI.

If you use pins that don't have a hardware port, it gives software only.
Use hardware pins, and it'll default to hardware SPI, unless you use the
command 'FORCE_SW'.

Hardware SPI transmits while the processor can be doing other things.
The instruction at it's start tests if the hardware is busy. If it is, it waits
till the hardware has finished it's current job. Then loads the byte to send. If
you have not asked to read the reply, it returns immediately. If you have
asked for the reply, it waits for this. Because it returns immediately if
a reply is not requested, you can load a byte to send, and get on with
doing other things while the hardware is sending.
Maximum baud rate depends on the chip, but is typically Fosc/4, in
hardware mode. So one bit sent each instruction time. In software mode
it varies fractionally according to the SPI mode selected, but is typically
about 21 instructions/bit. So hardware is over 20* faster.
A slave device can only be built using hardware SPI. Since a slave
has to respond to the incoming clock from the master, and miss nothing
the hardware shift register is needed. This also allows a receive interrupt
to be generated and used (Temtronic's comment above).
The SPI hardware input pins normally have Schottky buffers. These
require signals to go up to typically 0.7 or 0.8*Vdd to be seen as a '1'.
Software SPI may (depending on the pins chosen), instead only need
'TTL' levels (normally 0.25*Vdd+0.8v). So the difference between needing
the signal to go up to possibly 4v, and just over 2v. (My comment above).
spi_xfer, can send/receive 8, 16, 24 or 32 bits (in hardware mode).
You can use odd numbers of bits in software mode. (So 4 bits is legal
in software mode, but not in hardware mode).
If you select the hardware port, the capabilities are constrained by what
the hardware can do (hence the 8bit multiple limitations for example).
The data sheet is vital.

SPI is potentially a very fast interface. To use this speed needs the hardware
interface. Software is not 'slow', but is relatively much slower. For example
sending a single byte in a loop, using a PIC4520, in software mode, takes
361 instructions. The same code in hardware mode takes just 72
instructions.

#USE SPI adds some lovely extensions to the hardware or software modes,
so (for instance), being able to send not just a byte, but a 16bit word
or 32bit word with one instruction, and the compiler will automatically
handle sending the required bytes. However on some chips the resulting
code is fairly inefficient (on DsPIC's in particular significant time can
be wasted). However for fast operation on these DMA is probably the
real solution instead.

Also, as a further comment. CCS has two different ways of handling SPI.

The 'old' way, only supported hardware SPI. It uses the instructions
setup_spi spi_read & spi_write. This was the traditional way of handling
the spi hardware.
Then the 'new' way is #USE SPI and spi_xfer. This method supports
both hardware and software spi. However _beware_ it can cause
major issues if you setup spi with #use, and then try to use the older
instructions with this (some parts of the #use setup are not compatible).
The manual very carefully does not refer you from one method to the
other. So the manual entry for spi_read, only refers to setup_spi, and
vice versa. #use only refers you to spi_xfer. It is assumed by the authors
that people reading the manual will follow the links given and won't try
to 'cross mix' the two forms. However they don't explicitly 'warn' about
the issues this may cause.... Beware.