CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Speeding up software SPI
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

Speeding up software SPI
PostPosted: Wed May 23, 2018 12:38 pm     Reply with quote

Just curious if anyone knows how to speed up a software SPI. I do not have the luxury of anymore hardware SPI's on my chip. Its the 24EP256gp206 chip running at 140MHz. Adding some new things to it.

Fastest i can get each bit is around 960nS need it in the 100nS - 200nS range if possible. It works as far as putting the proper info out the port but its just not fast enough. Would setting FAST_IO on that port speed it up at all?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed May 23, 2018 12:58 pm     Reply with quote

Post your software spi routine.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed May 23, 2018 12:59 pm     Reply with quote

yes, fast_io 'should' speed it up a bit(no pun intended).
you need to dump the listing for the SPI functions though...
jay
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Wed May 23, 2018 1:00 pm     Reply with quote

I probably should clarify that I am talking to WS2812 leds. I have looked at most other stuff here and implemented it fine with hardware SPI. I do have DMA's still open and could use modified PWM?
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Wed May 23, 2018 1:01 pm     Reply with quote

I'm using spi_xfer routines stock from the CCS libraries. I did not create my own.

The other issue may be that using software SPI will create a lag for all my other items that need to run at the same time, or is software SPI still semi, in the background.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed May 23, 2018 1:07 pm     Reply with quote

Why not just re-use one of the hardware SPI's?.

You can change the pin mapping during code execution, move it to the pins you want, and then put it back when you have finished this transfer.

Look at the PIN_SELECT sticky at the top of the forum.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Wed May 23, 2018 1:13 pm     Reply with quote

Not sure I could get away with that as I am reading an SD card on one and talking to a codec on the other. The codec is also on a DMA. So if I could even get that to work it would have to be on the SD card one which seems like I may not have enough time to do so. Might be worth giving it a shot though.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Wed May 23, 2018 2:36 pm     Reply with quote

I would also need to change the SPI clock speed. SD card can run way faster and the ws2812 needs pretty specific timing. I think i was using 6.5MHz for the ws2812 and I am running 20MHz on the SD card. How many cycles does it take to chnage the clock frequency back and forth? Because the more I think about this the better the idea sounds.
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Wed May 23, 2018 7:46 pm     Reply with quote

For some versions of PCD, the spi_xfer routine and #use spi add a lot of code that can slow it down. Specifically it puts in code to select the size of the data (8,16,24,or32). You might dump the assembly listing and see if that is the case for your version. If so, writing your own manual SPI routines might come out faster.

EDIT:
Here is an old post where I show how this happens for hardware SPI, but it can apply to software SPI as well for some versions:
https://www.ccsinfo.com/forum/viewtopic.php?p=210851#210851
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu May 24, 2018 12:37 am     Reply with quote

However that will give him gaps between the bytes, not the slow clock rate.

I'm puzzled actually. Have just tested software SPI on a closely related chip at the same Fosc, and it is merrily giving bit clocks at 243nSec. About 4* his speed. 17 instruction cycles/bit. This with the #use programmed to 8bits.

Fast_IO makes no difference to the software SPI. It sets the tris once at the start of the transaction, not for every bit.


Last edited by Ttelmah on Thu May 24, 2018 10:40 am; edited 1 time in total
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Thu May 24, 2018 3:28 am     Reply with quote

curt2go wrote:
Not sure I could get away with that as I am reading an SD card on one and talking to a codec on the other.


Eh? With reasonable systems design, one SPI port should be able to meet your needs.

You can talk to as many devices on one SPI as you have IO bits to use as enables. It is common to connect many devices to a single SPI port. Changing speeds (often not actually required, but people want to do it anyway) is just a matter of changing a SFR. DMA clearly complicates things a bit, but then it should be possible to reasonably easy to use DMA for every transfer, just reconfiguring which buffer the data comes from/goes to.

In any case, with firmware, speeding up a few percent is usually possible, but ten times faster requires some/better hardware.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Thu May 24, 2018 6:16 am     Reply with quote

Thank you for the input. Ttelmah not sure how your getting such a fast speed. Maybe something on my end, but I do have a lot of other stuff going on , on that chip. I am also running 8 bits.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Thu May 24, 2018 6:55 am     Reply with quote

curt2go wrote:
Thank you for the input.


Okay :-| Why do you think you need more SPIs? What restriction is stopping you using just one?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu May 24, 2018 8:01 am     Reply with quote

Have to agree with the comments on just using one SPI. The SD has a CS line, so assuming the other device does, they can both use the same bus.

On speed have you actually tested your system genuinely is running at the speed it should be?. The old 'pulse an LED' test and verify you genuinely do get the expected speed. I must admit 17 instructions per bit is exactly the figure I remember from previous tests on the software SPI as it's 'upper limit'. Gives just over 4MHz from a 70MIPS processor.

Just using:
#use SPI(MASTER, DI=PIN_B2, DO=PIN_B3, CLK=PIN_B4, stream=SOFT_PORT1, bits=8)

Which gives the maximum speed supported.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Thu May 24, 2018 12:15 pm     Reply with quote

I get that I can use just one. I don't even need a chip select in this case as I will be remapping the SDO pin each time. So no CS would be needed. I will be trying it this weekend. Also I am pretty sure I'm running at full speed, I did all The tests originally to make sure but that was over a years worth of code since then. I'll let you know how it goes with each.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group