1
\$\begingroup\$

I'm learning how to control the L3GD20 gyro. sensor using STM32L4. In the datasheet of the sensor, Figure 13 shows how the master device should communicate with the sensor via SPI. My goal is to read the 'who am I' register at 0x0F. The register value is expected to be 0xD4, according to the datasheet.

If I have understood the sensor datasheet and the reference manual of the MCU, then the following approach should be reasonable.

(1) 16-bit data should be written to the SPI_DR register of STM32L4. Then the data are stored in the TXFIFO buffer in the MCU and then transmitted to the sensor through the MOSI line.
(2) In the full-duplex SPI mode, a reading operation happens simultaneously with the writing operation. So, the RXFIFO buffer in STM32 is filled with the 16-bit data received from the MISO line. The first 8-bit will be 0b11111111 and the next 8-bit should be the value stored in the "who am I" register.
(3) When the SPI_DR register of STM32L4 is read, the 16-bit data, 0xD4, in the RXFIFO buffer is read.

However, it looks like people do not use 16-bit long packets when they communicate with this sensor. Instead, many people use 8-bit write/read functions. Can someone please explain why one has to use 8-bit write/read functions?

To me that looks unreasonable. Figure 13 shows clearly that a packet should be 16-bit long. Obviously, there's no delay between the address bits and the data bits. This means that even a short delay is not allowed between the write and read operation.

I'm having a problem with reading the 0xD4 value but didn't want to show all my source codes. That would be too lengthy and chaotic. I hope that this question is clear enough.

\$\endgroup\$
3
  • \$\begingroup\$ If no delay were allowed between the address & data bits then the sensor's manual would indicate this. Since it does not express this requirement (and such a requirement would be extremely unusual), we can safely assume that any arbitrary delay is ok - and why would it not be? The SPI slave state machine inside the device is only clocked by the SPI clock supplied by the master - so if the master delays and does not toggle the PIS clock then the slave device simply remains in the same state waiting for the next clock edge. \$\endgroup\$
    – brhans
    Commented Jan 30, 2022 at 17:53
  • \$\begingroup\$ @brhans I realized that I put a wrong link. The link has been fixed. Now you can see the Figure 13 (read protocol). Would I have to conclude that this figure is very misleading? \$\endgroup\$
    – SD11
    Commented Jan 31, 2022 at 4:10
  • \$\begingroup\$ No it's not at all misleading - you're interpolating information that's not there. All that figure (and the text below) tells you is that CS must remain low for the duration of the command, 16 clock pulses are required, SDI must provide the appropriate command bits on the 1st 8 pulses, and SDO provides the corresponding data on the 2nd 8 pulses. There's no indication in there of any particular set of timing restrictions. The timing characteristics are all in section 2.4.1 on page 11. And there you also won't find any restriction on the inter-byte delay - because there is no such restriction. \$\endgroup\$
    – brhans
    Commented Jan 31, 2022 at 15:38

1 Answer 1

1
\$\begingroup\$

The largest reason people use 8-bit byte based transactions on a SPI bus is that all MCUs support it and not many MCUs support anything else.

Even if you can use 16-bit transactions for communication, it only works when you have a command/response message that is divisible to 16-bit transactions.

It would be difficult to support a transaction that requires transaction of 3 bytes, it does not divide to 16-bit operations.

And the assumption that no gaps in the transmission are allowed has no proof. Even if continuous transmissions were required, you would have an equal problem with gaps no matter if the transactions are 8-bit or 16-bit. And transactions can be made continuous, regardless of them being 8 or 16 bits, most MCUs are quick enough, may have some FIFO and even your STM32 MCU can use DMA for the transactions.

So, you don't have to use 8-bit transactions, but it is very easy and makes life simple, so there is little point in doing it in any other way that is more complex.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you for the reply. Could you also comment on Figure 13? I think this is a proof of the no gap requirement. Or, this figure is totally misleading. \$\endgroup\$
    – SD11
    Commented Jan 31, 2022 at 5:05
  • 1
    \$\begingroup\$ What about it? Looks like any other generic SPI data transfer diagram. A block diagram. Even if it has no pauses it does not mean the bytes need to be continuous. You can transfer bits as slowly you want, there is no limit for that. \$\endgroup\$
    – Justme
    Commented Jan 31, 2022 at 5:08
  • \$\begingroup\$ Okay, the logic level of CS does not go up in between the address and data bits. Also, the length of the SPC clock is 16-bit. Then isn't it natural to think that one packet is 16-bit long? I know the device supports 8-bit packet. But since I'm learning, I wanted to check if I'm misunderstanding datasheets. \$\endgroup\$
    – SD11
    Commented Jan 31, 2022 at 5:14
  • 1
    \$\begingroup\$ It even reads below your figure of interest that to transfer multiple bytes, just add any multiple of 8 clocks. As some registers may be longer that one byte and you might want to read multiple registers in same transaction, no, it is not natural to think in 16-bit packets but packets of any amount of 8-bit bytes. Your idea of using 16-bit SPI transactions is not wrong, it could be a neat idea, I have never thought of it like that, but different chips have different protocols and 8-bit byte oriented transfers are more generic and available. \$\endgroup\$
    – Justme
    Commented Jan 31, 2022 at 5:24
  • \$\begingroup\$ The 'multiple bytes' in the text means more than 2 bytes. But it does not mean that a packet can be as short as 1 byte. As far as I see all registers are 8-bit long, and a multiple byte transaction is done when the user wants to access several registers in a row, for example, reading the sensor readout for the X, Y, Z axes. You're right. Other devices support 8-bit long packet. Anyway, it was frustrating for me to see that I might be misunderstanding this datasheet. \$\endgroup\$
    – SD11
    Commented Jan 31, 2022 at 5:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.