This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Receive 1 byte from SPI

I want to receive only 1 byte (Master in Slave out) without sending any bytes using using SPI. However when I monitor the SPI clock it produces 16 clock pulses. Although my application works, I would prefer it produces only 8 clock pulses.

When I use the same procedure to receive 9 bytes it correctly produces 72 clock pulses. In this example spi_rx_num is 1.

err_code = nrf_drv_spi_transfer(&m_spi, spi_tx_data, 0, spi_rx_data, spi_rx_num);

My problem is the ADS2192R which requires approx 10us between each SPI transfer when issuing a read register commend. I send the 2 bytes of the commend correctly to read 1 register, but I cannot perform a read of a single byte.

  • 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.

  • 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.

Related