Difference between <#USE SPI> and setup_spi()

[benoitstjean]

Compiler: 5.026
Device: PIC24EP512GP806

Yet another question that needs clarification where manuals and help files are not always ideal (in my case anyhow!).

My MCU is tied to two external SPI devices on SPI3 (pins RE7, RE3 and RE2):

Device 1 uses RE4 for /CS (EEPROM 24LC1024)
Device 2 uses RF0 for /CS (ACCELEROMETER ADXL0345)


Of course, ideally, I want to take advantage of the maximum speed when accessing either device.

Initially at MCU startup, I am using the following to configure SPI3 because that's how the SPI bus needs to be configured for the EEPROM:

setup_spi3( SPI_MASTER | SPI_XMIT_L_TO_H | SPI_CLK_DIV_16 );

Then later in the code, I have functions that use spi_write3() for accessing both devices. So far so good, all works fine, no issues here, its been like this forever.

But as I learn more and more while working on this project, I am wondering if I am really taking advantage of the full SPI bus capabilities.

When I need to read or write to either device, the only differece is with the accelerometer's SPI configuration when I need to access it:

1) I must first call setup_spi3( SPI_MASTER | SPI_XMIT_L_TO_H | SPI_H_TO_L | SPI_CLK_DIV_16 );
2) Then I can read or write to the device;
3) Lastly I must call setup_spi3( SPI_MASTER | SPI_XMIT_L_TO_H | SPI_CLK_DIV_16 ); to put the SPI bus back to 'EEPROM' mode since it is accessed much more often.

The accelerometer is rarely accessed after it is initially configured, the EEPROM is more accessed therefore I set the SPI back to the 'EEPROM' mode.

All this being said, hoping I didn't give too much irrelevant information, what is the difference between setting-up the SPI port with setup_spi vs #USE SPI?

Is there a difference in speed when the device is accessed? I haven't tried using the #USE SPI because I am not sure what else is required when using that fuse.


Thanks,

Ben

[PCM programmer]

[benoitstjean]

Hi PCM Programmer, correct, typo from my end, it is a 25LC1024.

Ok for the modes... thanks.

But the general question is still valid:

What is the difference between setting-up the SPI port with setup_spi vs #USE SPI?

And which SPI 'model' will take advantage of the max speed of the SPI bus?

Thanks again,

Benoit

[Ttelmah]

setup_spi, is the older way of using the SPI.

Only works with hardware ports.
Uses spi_write and spi_read for transfers.
Only supports 8bit transfers.
Does not offer any control of handshake lines.
Requires direct control of the configuration bits (directions, levels etc.). Simpler defines for these though are easy.

#USE_SPI is the more powerful 'modern' way of controlling SPI.
Supports software and hardware ports.
Requires spi_xfer for the actual transfers.
spi_xfer is coded slightly differently. For a transmit transfer, on the hardware port, it'll check if the peripheral is 'free' before transferring a byte, then transfer _and immediately return_. This means you code can be preparing the next byte while this transfer is occurring.
Supports automatic multi byte transfers (up to 4 bytes).
Can control latch and enable pins.
Supports 'mode' names for configuring the port.
Also allows you to specify bit order and byte order for the transfers.

SPI_XFER for sequential writes is faster, because of the ordering of the 'device ready' test.

[RF_Developer]

In terms of bus clock rate, they will both give the same maximum. Any difference in throughput will be due to firmware overheads, giving slighty larger gaps between transfers.

I am running a 25AA1024 on a PIC24HJ128GP504 on 3.3V. The bus lines are maybe 30mm long. I cannot reliably run at the maximum SPI clock rate that the 25AA1025 of 10MHz as even with the short, direct PCB traces, I am getting a lot of overshoot and ringing, making the waveforms a bit dodgy. So, I've had to slug the SPI to 5MHz (the clock rate divider only allows, obviously, integer sub-multiples of my Fcyc, 80MHz, so I can have 20MHz, 10MHz, 5MMhz, 2.5MHz, etc. but nothing in-between) to get reliable transfers in all my available hardware (granted not many: one prototype board worked fine, one didn't... sometimes). I could have probably fiddled wround with termination resistors to improve the waveforms, but there was no need, running at half-speed is just fine in my application (serving wepages on a LAN). So, I'd not recommend running at top speed for the sake of it, and it may not be easy to guarantee.

[benoitstjean]

Hi guys,

Thanks both for your replies, it's appreciated.

So maybe then when I get a bit of time, I will look at using the more "modern" version.

Thanks a lot!

Benoit

[jeremiah]

It's worth noting that at least for some chips for some compiler revisions, the #use spi generates slightly more code and takes a few instructions longer (for hardware mode).

Consider:

[Ttelmah]

Interesting.

On the spi_write code. Note that it waits for the peripheral to be ready before sending, and then again afterwards.... :(

Now the multi byte code is silly. As you say it should not include this if you are fixing the transaction length. It doesn't on a PIC16/18.... Duh.