RE: SPI Clock BUG

RK — Fri, 09 Oct 2015 11:21:53 GMT

We discussed this a while ago in devzone.nordicsemi.com/.../ plus some others. I have about 3MHz running, Clem said he got 4MHz. That required not using the SPI Master driver but writing our own which, when it gets an interrupt, keeps filling the TX buffer as fast as it can until it runs out of characters or manages to fill the buffer, at which point it waits for another interrupt.

RE: SPI Clock BUG

MartinBL — Fri, 09 Oct 2015 08:58:30 GMT

This is due to overhead in the spi_master.c driver. Sadly there is no easyDMA in the master SPI on the nRF51 so in the driver an interrupt is called after every transmitted byte. The interrupt routine is responsible for handling incoming bytes and load new bytes to the transmit register which takes time. The SPI is double buffered meaning that the second byte can be written to the TXD register immediately after the first one. In other words, the SPI driver is not using the interrupt handler to load the second byte so there is almost no overhead. The following bytes however, are loaded into the TXD register using the interrupt handler creating an overhead.

I did some experiments and it looks like you actually won't get any higher throughput by increasing the frequency above 1MHz if you use the driver in the SDK:

You can probably make your own interrupt routine though, customized for your own needs that will work faster than the one in the SDK.