RE: Receive 1 byte from SPI

Malcolm — Wed, 14 Apr 2021 12:51:48 GMT

Thank you for your rapid response. I tried slowing the clock, but this still did not give reliable results. I have therefore returned to my original solution to send byte by byte and insert a gap (conviently about correct given delay to process the SPI event). As I only use this during initialisation it is not an issue. This means I can use maximum speed for SPI and a single call to retrieve the 9 bytes of the data sample.

RE: Receive 1 byte from SPI

hmolesworth — Tue, 13 Apr 2021 17:28:36 GMT

Have a look at this unexpected-transaction-length. There is an errata (58) for the nRF52832 causing the effect you observe. The 10uS can be achieved by slowing down the SPI transfer clock. For the delay this note might help (I wrote this for a different ADS chip):

// Sending Multi-Byte Commands
// The ADS1291, ADS1292, and ADS1292R serial interface decodes commands in bytes and requires 4 tCLK cycles
// to decode and execute. Therefore, when sending multi-byte commands, a 4 tCLK period must separate the end of
// one byte (or opcode) and the next.
// Assume CLK is 512 kHz, then tSDECODE (4 tCLK) is 7.8125 us. When SCLK is 16 MHz, one byte can be
// transferred in 500 ns. This byte-transfer time does not meet the tSDECODE specification; therefore, a delay must be
// inserted so the end of the second byte arrives 7.3125 us later. If SCLK is 1 MHz, one byte is transferred in 8 ï¿½s.
// Because this transfer time exceeds the tSDECODE specification, the processor can send subsequent bytes without
// delay. In this later scenario, the serial port can be programmed to move from single-byte transfer per cycle to
// multiple bytes.