Difference between TransferFullDuplex and TransferSequential for spi

I give a try with both functions:

ReadBuffer give me: (in that order!): 0x92 0x00


ReadBuffer give me: (in that order!): 0x92 0x00

So my first question is what is the difference between functions as they seem to have same behaviour.
Another question is why I got 0x92 before 0x00 because logic analyzer give contrary ?!? :face_with_raised_eyebrow:

Below is code:

        private byte[] ReadRegister(byte register)
            register <<= 1;
            register |= 0x80;
            return TransferSpi(new byte[] { register, register, 0x00 });

        private byte[] TransferSpi(byte[] writeBuffer)
            var readBuffer = new byte[writeBuffer.Length];
            _device.TransferSequential(writeBuffer, readBuffer);
            return readBuffer;

Dunno, as seems TransferSequential() is FullDuplex to.
Maybe some backwards compatibility naming change at some point?

SPI hardware is always full duplex but if you use sequential it will write the bytes you give it and then follow it with zeros sent to read the bytes you requested.

Thanks for explanations.

Furthermore, I don’t know why, but yesterday, what I see isn’t correct. I retry this morning and time chart (can you confirm is this the good word ?) are now correct.
The reason that values order isn’t correct was I use foreach to display them, now I use a for loop and all is OK.

To resume:
With TransferFullDuplex:

  • I send a writeBuffer (of 2 byte size): 0xee, 0x00,
  • I receive a readBuffer (of 2 bytes size, same as writeBuffer): 0x00, 0x92

    Time is shorter to send 2 bytes but needs more memory for buffer (2 * 2 bytes)

With TransferSequential:

  • I send a writeBuffer (of 1 byte size): 0xee,
  • I receive a readBuffer (of 1 bytes size, same as writeBuffer here but not necessary): 0x92

    Time is longer to send 2 bytes but needs few memory for buffer (1 * 2 bytes)

@Bauland SPI is better used in FD mode whenever possible. In the last years many chip makers are using the same shift-register decoding logic on-chip for both SPI and I2C, normally for chips that can work on both buses (save money :slight_smile: …). This is why some peripheral chips needs a sequential transfer. This is like the repeated start on i2c and if you see your diagram, MOSI is going to be streched high for a while (it seems too much in this case… ).