SPI optimization

RE: SPI optimization

ovrebekk — Fri, 11 Dec 2015 14:13:09 GMT

It is good to hear that the driver made the difference ;)

RE: SPI optimization

Emil — Thu, 10 Dec 2015 12:37:24 GMT

Thank you so much. The driver shipped with the SDK was simply not enough to do big multibyte reads on the ADXL362. With your fast SPI driver, it solved the problem!

RE: SPI optimization

ovrebekk — Thu, 26 Nov 2015 15:29:06 GMT

I am happy to help :)

Feel free to accept my answer if you are happy with the response.

RE: SPI optimization

valdev — Wed, 25 Nov 2015 10:50:27 GMT

Many thanks for your help!

RE: SPI optimization

ovrebekk — Fri, 20 Nov 2015 14:41:47 GMT

The official driver is interrupt based, and this adds a bit of overhead to each byte transfer. I wrote a polling based driver a while back, and it will be significantly quicker when running at higher bitrates: spi_master_fast.zip

As mentioned above the SPI master is only ratified up to 4MHz, and the reason for this is that we can not guarantee that the fall/rise times of the GPIO's will be quick enough to support 8MHz operation under all circumstances. By using the SPI at 8MHz you risk getting a system that works fine on one board, but fails on another for instance.

Under testing I find the library to give you a bitrate of approximately 4.2Mbps at 8MHz, and 3.5Mbps at 4MHz, so you are not gaining a lot of speed by using the 8MHz mode either.

At 4MHz the driver runs at about 90% of the ideal bitrate, and at 2MHz or lower it runs at 100%.

Best regards
Torbjørn

RE: SPI optimization

valdev — Wed, 18 Nov 2015 15:09:53 GMT

Thanks I gonna work on it!

RE: SPI optimization

EDJ — Wed, 18 Nov 2015 14:57:45 GMT

Hello: there are NORDIC drivers that are good but somewhat heavy in their overhead. The drivers employ software FIFOs, critical sections, etc. If you are sending a small number of bytes, and can wait for the transfer to complete, then it can be much faster to assert chip select, write 2 bytes to the SPI data register (it is double buffered), wait for two bytes to come back, and repeat until your transfer is done; then de-assert CS. Do this with interrupts enabled so that RF processes and timers can continue to run. You can still use the SPI driver init function, but disable ints from the SPI port after initializing, since you will be polling.

Also, it helps to have a logic analyzer on the SPI port; you can infer from that where the SW delays reside.

RE: SPI optimization

Wojtek — Wed, 18 Nov 2015 14:41:22 GMT

I cannot help you with the case you asked, but there is one thing about spi: according to newest product specification (i assume you are using nrf51822) the max frequency is 4M, NOT 8M (although it is defined in SDK). You shouldn't go above 4mbps (i don't know exact reason why it is like that...) Some info here.