SPI #use spi()

[miro]

Hi, I am running a code (r/w to an external fram) with pic24hj128gp502 in 4.104 with this setting:

[FvM]

Do you expect any advantages from #use SPI?

So far, I see only restrictions, e.g. it's impossible to change speed and SPI modes, as required for some
applications. So I didn't feel yet a need to explore possible bugs related to this function.

[ckielstra]

'#use spi' is supposed to be the 'newer and better' replacement for the setup_spi command. _Never_ use these two SPI configuration commands for the same SPI port or undefined behaviour might be the result. So, your demonstration program is bad coding practice.

The advantage of the '#use spi' directive is that it is more versatile, i.e. it accepts more parameters than the setup_spi command and if the hardware module doesn't support the given parameters, then a software emulation is created. This allows for example to have 12-bit SPI with bit-reversal on a pin that has no hardware SPI support.
The big problem with '#use spi' however is that it is new and most likely contains bugs (at least the last time I checked it in v4.087).

[FvM]

[miro]

Thanks guys, after some experimenting I've learned the best solution is to hardcode it directly:

[FvM]

SPI1CON1=0x027e doesn't correspond to the above said SPI setup, it sets mode 3 with additional late sampling.
SPI_H_TO_L sets mode 2 (SPI1CON1=0x017e) in recent PCD versions, and mode 3 in previous (SPI1CON1=0x07e), e.g. in V4.104. But which SPI mode do you intend?

[miro]

@FvM: These two setups work for me:
SPI1CON1=0x007e; // or 0x027e works as well
Using the "setup_spi(SPI_MASTER | SPI_MODE_3 | SPI_CLK_DIV_4 );"
does not work for any "SPI_MODE_x" ..
The Fram FM25H20 needs the spi mode 0 or 3.
Miro

[victorcastro89]

I'm new in hardcode, i'm reading datasheets many times and can't configure SPI slave and mode=1 with SS.
Anyone can help me?

[miketwo]

Not sure if this will help, but this is the code I use to change spi settings between calls to my flash and my gyro. This is all on a PIC24FJ256GA110, but it should be similar to yours:

[victorcastro89]

[RckRllRfg]

Hi Everyone -

I've spent a fair amount of time on the SPI for the PIC16F1947. Granted, I have the luxury of the SPI being a one way communication, from the PIC to the slave component.

If is VERY important to note that the #use spi and setup_spi commands are not compatible (nor is setup_spi and #use i2c, but that's another story... )

I originally used a bit banging method to get it to work; however, I really need to use the hardware SPI since I must provide an update via DAC 30,000 times a second. In this case, all I want to do is provide the 16 bit word to the hardware SPI and let the hardware do the rest. I don't want to spend any time hassling with the registers within the code (beyond configuration). But, then again, the limitations of the #use spi may force me to consider otherwise.

Just to note, most of my learning on the SPI was done via O-scope. If you have one, I high recommend that to connect your CS, LOAD, CLK and DATA lines to see what you are sending or receiving.

In my particular case, I am targeting a MCP4822(SPI to DAC). The PIC provides dedicated pins for CLK, DI and DO. My CS pin had to be declared in the #use SPI declaration. The #use SPI would not accept my LOAD signal, claiming that it wasn't allowed when declaring the use of the Hardware SPI. It's a non issue for me, given that I can keep the LOAD signal active at all times;however, if multiple slaves were involved this could be an issue.

I do have some minor issues and I may comment on them in another post. However, it looks like it will do what I need done within my window of 33us (approximately 18us, though I would like to condense this further). I am using compiler version 4.124.

Here's my code, if you wish to give it go. Note that I stripped out other code, so hopefully I did not compromise it. The code is set up to create an ascending staircase on ChannelA and a descending staircase on ChannelB.

[PCM programmer]

[asmboy]

Let me add to all thats been said:

I've done a variety of SPI peripheral drivers, and when the
slave device is input only - I've never had issues with setup_SPI();
and using the hardware send SPI_write function.

And there really is no issue with ANY SPI word length either, in spite of having to clock a byte at a time.

I've clocked 4,8,12,16,20,24,30,32 and 36 bits using the hardware interface.

The secret is in understanding that you can pass MORE bits to an spi device
than it needs - so LONG as the LAST 'n' bits are in the right order.

Once you grasp that notion, delivering those bits with hardware ,
I IMHO, can be the most efficient way to get it done.

[RF_Developer]

I've been experimenting. Using PCWH 4.125 targetting PIC18F6722 (for no particular reason other than I had a handy test project, and it has two MSSPs) and lookng at the listing file to inspect the assembler produced. These trials confirm what I wrote on another recent thread. That is that setup_spi() and spi_read()/spi_write() use the hardware SPI, #use spi and spi_xfer() implement a software virtual SPI.

More importantly, in my tests, FORCE_HW in #use spi had no effect (it may be a place holder for later use...). No matter what I did if I put in #use spi I got a software implementation. If I used setup spi() I got hardware initialisation code, and spi_read() gave me a hardware transfer.

The MSSP hardware that implements SPI on the PICs is byte based. It can only transfer bytes at a time. If you want to transfer 16 bits then you have to programmatically issue two transfer requests, each transferring a byte. As Asmboy says you can always send more than you need, say 16 bits when you needed a 12 bit transfer, but you cannot send anything other than multiples of 8 bits. You should set the SPI bit rate for hardware SPI as the PIC may (unlikely to be fair but *may*) be able to transfer faster that the external peripherals are able to cope with. SPI peripherals always have a maximum SPI clock rate specified in the datasheet: run the SPI at the speed of the slowest device, or slower. The hardware SPI cannot run faster than 1/4 of the processor clock. In your case at 20MHz that's 5Mbps, which is as fast as most ADCs and DAC can handle. Memory tends to be faster, being typically capable of 20MHz and more, 40-50MHz is not uncommon. PICs simply cannot run the SPI that fast. I managed to run an NXP ARM SPI at 20MHz, but that was fully buffered and could transfer blocks of bytes without any software intervention, which is how serial memories work most effectively. The PIC SPI hardware is strictly a byte at a time.

The hardware SPI is fast and processor efficient. It should be able to be fully interrupt driven giving asynchronous (non-blocking) transfers but I've not seen any code that does that, and you'd have to roll your own. 30,000 transfers a second is very fast, suicidally so for a PIC. Its probably doable, just, but the PIC will literally not be doing anything else. I have code that does something that fast, it reads an ADC asynchronously. I read then start the next conversion immediately. The ADC converts while I'm processing the previous sample. I maybe change a few bits - six to a digital attenuator - if required. That's all. I have a CAN interface and that runs on interrupts. If I have to respond to a message the loop stalls for quite a while.

#use spi generates software SPI. That runs much more slowly than the hardware can. This means that speed is rarely an issue and most folk simply don't bother to set the speed and thus will tend to wonder what on earth I was talking about in the paragraph above. I doubt you'd be able to get more than 1Mbps from a software SPI on PIC but I haven't actually timed them to confirm that suspicion. While the PIC is transferring data by software it can't be doing anything else, unlike hardware which can be asynchronous. That's fine for a SPI master, but not so good for an SPI slave.

The software SPI is much more flexible than the hardware. You can transfer any number of bits you like, on any pins. Enables can be done for you. Its simple... but slow. Its not so good for slaves which have to be prepared for transfers at any time, and when they start simply have to keep up with the clock rate, otherwise they corrupt or loose data.

So, why exactly do you need 30,000 DAC updates per second via SPI? That's frighteningly fast for a PIC. There's no way you'll get anywhere close without hardware, and FORCE_HW simply doesn't work (and would be incompatible with sending 16 bits at a time).

RF Developer

[RckRllRfg]

RF_Developer et. al. -

Thank you for the further insight between the #USE SPI and the setup_spi. As a side note, the CCS manual needs to make some clarifications on this subject... but this is why we have the forums.