SPIM buffer lengths -- how to calculate and specify

RE: SPIM buffer lengths -- how to calculate and specify

RVM — Thu, 03 Mar 2022 15:40:03 GMT

From my understanding, SPI systems are 'serial' and 'duplex' so I fail to understand why the need to compare the maximum number of transmit bytes to the maximum number of receive bytes -- one should simply pick an order and stream all the bytes sequentially. In my specific case it turns out to be that the SPIM should stream OUT 1 command byte and then stream IN the next 10 receive bytes -- for a total of 11 data transmit clocks. I simply do not see why there is a need to expect any other values for the two 'length' parameters (such as the 11 I had to specify to get the SPIM to talk correctly to the MCP2515)

RE: SPIM buffer lengths -- how to calculate and specify

RVM — Thu, 03 Mar 2022 15:33:09 GMT

Perhaps it will help if I paraphrase my original observations.

It is not the SPIM hardware that is the issue but rather Nordic SDK's firmware design of the spin lock in the SPIM driver that manages the transfer.

Going back to my original example of 1 command byte and 10 receive bytes.... I get receive buffer underrun UNLESS I set both the RXLENGTH and TXLENGTH to be (10+1).

I was expecting that setting TXLENGTH to 1 and RXLENGTH to 10 'should work' (as suggested by both mrono and Jorgen) but it did not -- regardless of the ORC byte.

RE: SPIM buffer lengths -- how to calculate and specify

Jørgen Holmefjord — Thu, 03 Mar 2022 13:04:36 GMT

Hi,

Although your SPI slave works this way, does not mean every SPI slave will work the same way. I'm quite confident that your code will work equally well if you set the tx_length to 1 and rx length to 11, as mentioned by mrono, the SPI peripheral will clock out the ORC byte when the tx_length have been reached. The typical SPI protocol will output the RX data after receiving the command, but this is not always the case.

SPI works as a shift register, bits are clocked in and out of the register on each clock cycle. The SPI protocol does not care how the data in the registers are used, but it will always clock in and out data at the same time (given that the MISO/MOSI pins are connected of course). In the typical case described above, you need to set the rx_length to the expected read length + the length of the command, as the SPI peripheral will start filling the RX buffer when the command is clocked out. However, some SPI slave may implement a protocol where you do not need to send a command byte with each read, the slave may be configured to only clock out a preconfigured value on each read. Or the SPI slave can for instance clock out data for the previous command on MISO line while receiving a new command on the MOSI line.

As you can understand, it is much more flexible to allow the user to specify both tx_length and rx_length as separate parameters, as the lengths will not always be the same.

Best regards,
Jørgen

RE: SPIM buffer lengths -- how to calculate and specify

mrono — Thu, 03 Mar 2022 08:57:19 GMT

This is what the datasheet says:

When the maximum number of bytes in the receive buffer is larger than the number of bytes in the transmit buffer, the contents of register ORC on page 424 will be transmitted after the last byte in the transmit buffer has been transmitted.

So it is a feature. No need to specify a tx buffer larger than necessary. I'm not sure how the spim driver handles that. Based on your description not very well.