What can function named ReadWrite do in SPI communication? - embedded

Question

I'm using MPSSE library to have SPI communication via PC.
There are 3 main functions which handle communcation via SPI:
SPI_Read - for reading
SPI_Write - for writing
and the third one
SPI_ReadWrite, described as:
this function reads from and writes to the SPI slave simultaneously. Meaning that one bit is clocked in and one bit is clocked out during every clock cycle.
and I can't get the difference between them like in SPI signals...
What's the purpose of using it, if in SPI we need to serially do writing and reading.

Answer 1

Generally, a SPI transfer is always bidirectional, if we look only at the wires.
With SPI_Read() you need to look into its source or watch the sending wire to learn what is sent. Probably it is all 0 or all 1. However, only the received data is returned, and the caller does not need to provide data to send.
With SPI_Write() the received data is ignored. The caller has to provide the data to send.
And SPI_ReadWrite() reveals the true nature of this interface. With each clock one bit is sent, and one bit is received. Data to send must be provided, and received data is returned. The number of bits is the same for both directions.
It all depends on the communication partners how they handle it.

Answer 2

All operations on SPI are simultaneous read/write. The read-only function must write "dummy" data, while for the write-only function data is read and discarded. Most likely if you look into either SPI_Read() or SPI_Write() you will find that they are both implemented using SPI_ReadWrite(). At least you would with an MCU implementation, the MPSSE code is not SPI code but USB code for communicating with FTDI SPI/USB bridge devices, so the simplicity of SPI is not really apparent - USB is massively more complex but unlike SPI is half-duplex (excepting USB-C SS modes), so cannot truly perform simultaneously read/write - that is performed by the FTDI device not the USB connected PC which has a "virtual" SPI port
The reason is that the master and slave SPI roles are implemented as single shift-registers connected in a loop; as the master clocks data out one end of its shift-register, new data is simultaneously shifted in from the slave, so that after one complete word-write operation, new data from the slave will be present in the master shift register.
The nature of SPI is indicated by the signal names - master-out/slave-in (MOSI) and master-in/slave-out (MISO)* - both occur, one bit per SCLK edge.
Attribution CBurnett from https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#/media/File:SPI_8-bit_circular_transfer.svg
In your case however what you have is:
----------------------------
| SPI/USB Bridge e.g. FT4222H|
---------- | ---------- ---------- |
| |<--SCLK---| | | ||
| SPI Slave|---MISO-->|SPI Master|<-->|USB Device||
| |<--MOSI---| | | ||
---------- | ---------- ---------- |
| ^ |
--------------------|-------
|
--------
|USB Host|
| (PC) |
--------
So the communications you are seeing is USB not SPI. The simultaneous read/write is occurring at the SPI Master/Slave level and bridged to USB art half-duplex (write followed by read). Note that Host/Device is simply a less loaded term than master/slave - the relationship and control are similar in that a USB device cannot initiate a transfer autonomously.
Not all devices can usefully exploit the simultaneous read/write capability; it is useful mostly in situations where input and output data are independent and streamed such as SPI UARTs, or perhaps in a proprietary MCU to MCU connection. In transactional operations, such as reading a device register or EEPROM memory location, you typically write a command or request and separately read the response, so separate read/write "facades" to the intrinsic read/write are provided so you don't have to handle the dummy data yourself.