My angle on this:
There are basically two types of transfers: single byte and multi-byte. When to use single byte or multi-byte is not dictated by the SPi protocol; rather it is how the slave device wants to communicate its data: which is fully described in the slave's datasheet.
In SPI, both single and multi-byte transfers start with the master pulling the Chip Select (CS) line low for the desired slave. The master then generates a serial clock (SCLK), and for each clock pulse, one bit of data is simultaneously transferred between the master and slave on the MOSI and MISO lines. This is the fundamental operation for any byte transferred.
The key difference lies in how the Chip Select (CS) line is managed. (and this fully described in the slaves' datasheet)
Single byte transfer:
In what could be considered a series of single-byte transfers, the CS line might be deactivated (pulled high) after each byte is transmitted.
Multi-byte transaction:
The CS line typically remains active (low) for the entire duration of the transfer of multiple bytes. This offers efficiency by avoiding the overhead of repeatedly activating and deactivating the slave. Importantly, some slave devices may abort a multi-byte operation if the CS line is deactivated prematurely.
The Raspberry Pi Pico C SDK provides functions like spi_write_blocking, spi_read_blocking, and spi_write_read_blocking that facilitate the transfer of multiple bytes in a single function call, keeping the CS line managed for the entire block transfer (though you still control the initial pull low and final pull high). Using PIO can also efficiently handle multi-byte transfers, leveraging FIFO buffers. You need to consult the slave device's datasheet to understand the expected number and sequence of bytes for its operations.
The SDK functions does a good job at controlling discarding unwanted bits and adding required dummy bits to solicit desired output from the MISO and MOSI line. The SPi protocol allows engineers to specify the low level handshaking and when to use multiple single byte transfers or to use more efficient multi-byte transfers. And this often is desirable. For instance writing a block of memory from the master to the slave can be done efficiently with a SPI multi-byte transaction: 1. Master: pulls CS line low; and sends address of Starting register in slave (slave now ready to accept multiple bytes from Master) 2. Master (still holding CS line low) send multi-bytes to the slave which is transfers to a series of registers with sequential address that auto increment.) But this whole process will describe in the slaves datasheet. Another device may take a totally different approach: again the datasheet is the key. If you are have controlled of both the Master and Slave, you get to dictate how they will transfer data: the OP here has total control; he gets to write the datasheet: lol.
There are basically two types of transfers: single byte and multi-byte. When to use single byte or multi-byte is not dictated by the SPi protocol; rather it is how the slave device wants to communicate its data: which is fully described in the slave's datasheet.
In SPI, both single and multi-byte transfers start with the master pulling the Chip Select (CS) line low for the desired slave. The master then generates a serial clock (SCLK), and for each clock pulse, one bit of data is simultaneously transferred between the master and slave on the MOSI and MISO lines. This is the fundamental operation for any byte transferred.
The key difference lies in how the Chip Select (CS) line is managed. (and this fully described in the slaves' datasheet)
Single byte transfer:
In what could be considered a series of single-byte transfers, the CS line might be deactivated (pulled high) after each byte is transmitted.
Multi-byte transaction:
The CS line typically remains active (low) for the entire duration of the transfer of multiple bytes. This offers efficiency by avoiding the overhead of repeatedly activating and deactivating the slave. Importantly, some slave devices may abort a multi-byte operation if the CS line is deactivated prematurely.
The Raspberry Pi Pico C SDK provides functions like spi_write_blocking, spi_read_blocking, and spi_write_read_blocking that facilitate the transfer of multiple bytes in a single function call, keeping the CS line managed for the entire block transfer (though you still control the initial pull low and final pull high). Using PIO can also efficiently handle multi-byte transfers, leveraging FIFO buffers. You need to consult the slave device's datasheet to understand the expected number and sequence of bytes for its operations.
The SDK functions does a good job at controlling discarding unwanted bits and adding required dummy bits to solicit desired output from the MISO and MOSI line. The SPi protocol allows engineers to specify the low level handshaking and when to use multiple single byte transfers or to use more efficient multi-byte transfers. And this often is desirable. For instance writing a block of memory from the master to the slave can be done efficiently with a SPI multi-byte transaction: 1. Master: pulls CS line low; and sends address of Starting register in slave (slave now ready to accept multiple bytes from Master) 2. Master (still holding CS line low) send multi-bytes to the slave which is transfers to a series of registers with sequential address that auto increment.) But this whole process will describe in the slaves datasheet. Another device may take a totally different approach: again the datasheet is the key. If you are have controlled of both the Master and Slave, you get to dictate how they will transfer data: the OP here has total control; he gets to write the datasheet: lol.
Statistics: Posted by Henderson Hood — Sun Apr 20, 2025 3:17 am