Speeding up software SPI

[curt2go]

I think last time I just used a delay_us(1) and then toggled an output and watched the frequency on a scope. Is there a better way to test the speed? I really hope I have not been running slower than I thought this whole time! Man the old 8 bit days were so easy. ;)

[Ttelmah]

Problem with that is the delays involved in the actual output operations. Do a toggle at a much longer interval like 10 seconds, and you can check with a stopwatch.

[curt2go]

Then I guess that takes any instruction lags out of there. Makes sense.... Thanks.

You would still use delay_ms(10000); then at that point. Or a timer?

[Ttelmah]

delay_ms.

The whole point is that this then tells you 'for sure' how long the compiler thinks 10 seconds is in instructions. If the figure is wrong, it says the chip isn't running at the speed the compiler expects.....

Now (of course), if this is 'right', we then have the question of why on earth the SPI rate isn't getting to the 243nSec period?.....

[curt2go]

Ok thought so. I really hope that it's still running at speed.... But it would help in other spots . I think I am getting 970ns which is 4 times slower almost exactly than what you are getting. I will be really mad at myself if this is really the case!

Thanks for all the input..

[curt2go]

Clock is correct.

Here is what i am using to set up the SPI.

#use spi(MASTER, DO=PIN_B11, MODE=3, BITS=8, stream=NEO_PIX)

I am only getting a 960nS bit width.

I am still going to try switching the pinout so I can use hardware SPI for both.

[Ttelmah]

Er. What pin is being used for the clock?.....
I'd suspect the SPI doesn't like not having a clock pin. After all it is a _synchronous_ bus, and therefore requires a clock.

[curt2go]

No clock needed for neo pixels.

[Ttelmah]

I'd suspect this is what is killing the clock rate. The SPI is not designed to support operation without a clock. The software is in a mode it is not written to support. Using the hardware SPI, you will have a clock pin.

[PCM programmer]

He has never said how he's measuring the bit rate. He might be
measuring it incorrectly. He has never posted the code loop that
sends the data. If he posted a complete test program, the issue
would probably be cleared up quickly.

[Ttelmah]

Very true.

[temtronic]

the 4x slower is kind of a 'red flag' to me, almost sounds like 'smthing' isn't getting set properly...

[curt2go]

Measuring bit rate with a logic analyzer. I actually would be getting 1/2 that as I was using 0xC0 to generate the bit length which is 2 hi's.

This code worked fine on a hardware SPI with baud of 6500000.

[PCM programmer]

In a previous thread, you said this:

[curt2go]

5.061 now..