Is there a burst mode for EasyDMA on SPIS?

[David Andresky]

Hi, I am developing an SPIS interface on the nRF51822 using SDK v12.3.

I have configured my device for EasyDMA and I expected to see a continuous stream of data being transmitted. However, I only see the first two bytes continuously transferred due to the dual buffering, every other byte after that has a pause. I have configured my application for 4Mb but the effective transfer rate is only about 1.8Mb.

Does the Nordic device support a burst or continuous mode of transfer?

[haakonsh]

1. "I only see the first two bytes continuously transferred due to the dual buffering, every other byte after that has a pause. "
   - I need a more detailed description.
2. "I have configured my application for 4Mb but the effective transfer rate is only about 1.8Mb."
   - The clock frequency/bit rate is not the same as the data transfer rate due to protocol overhead. What exactly is your SPIS configuration? 

 

[David Andresky]

1. I am using the SPI master example project in the SDK to test my slave implementation. This project repeatedly transmits the string "nordic". The first two characters are transmitted consecutively with no break between the characters. The remaining characters all have a break that is slightly longer in duration than the time it takes to transmit one character. I was hoping for a burst mode where all characters would be transmitted without breaks.

2. Attached is the sdk_config.h file. If I remember correctly, EasyDMA was configured off and I turned it on but saw no change in behavior.4466.sdk_config.h

[haakonsh]

1. I need a scope of the IO lines. I'm unable to understand your description
2. I did not find anything wrong in the config file, but I need to know the state of the SPIS and SPIM peripherals before a transmission occurs. 

[David Andresky]

[haakonsh]

This looks quite normal for SPI communication. SPI is not a continuous bit stream, but fragmented into packets of one byte. 

The two consecutive bytes at the start is the only thing that is out of place. If the SPIS can receive and transmit the data correctly then there is not really an issue here.