Hi,
I am currently experimenting with the MPU-9250 9-axis motion sensor while waiting for an ICM 20948 to arrive, and I have some questions about the behavior that I've found with the SPI implementation. I haven't yet found detailed enough documentation to answer these myself.
I am initially using the Python spidev package for experimentation, specifically its xfer methods that take a list of SPI register addresses to read from.
For convenience, I have defined the following two methods that call through to spi.xfer2 after setting the top bit to signify a read access to each register, and adding a dummy address to the end of the list so that the last returned value is fetched:
spi_read_bytes(reg_addr_list) -- this calls spi.xfer2 once with the whole list
spi_read_bytes_one_by_one(reg_addr_list) -- this calls spi.xfer2 once for each item in the list
It is worth noting that the MPU-9250 has documented and expected content to be returned when reading from register addresses: 0x00, 0x01, 0x02, 0x0D, 0x0E, 0x0F. However, register addresses 0x03-0x0C and 0x10-0x12 are undefined.
I have found the following, and I do not know SPI well enough to know whether these behaviors are expected, peculiarities with SPI itself, peculiarities with TDK's implementation, etc. Any info, including common knowledge is appreciated.
It would seem that when starting a transfer transaction that it does not matter what register addresses are included in the list beyond the first item.
For example, if I call:
spi_read_bytes([0x00, 0x01, 0x02, 0x0D, 0x0E, 0x0F])
I will receive data for addresses:
[0x00, 0x01, 0x02, 0x03, 0x04, 0x05]
where those last 3 items are not defined in the documentation.
If I call:
spi_read_bytes_one_by_one([0x00, 0x01, 0x02, 0x0D, 0x0E, 0x0F])
I will receive the intended data since I am using a CS-bounded transaction per address, so 6 separate transactions in this case.
Also, if I call either of these:
spi_read_bytes ([0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F])
spi_read_bytes_one_by_one([0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F])
then I will receive a 16-byte buffer with the first three and last three bytes valid and the middle 10 bytes presumably junk, the first of which are the same as the last three bytes that I received from the spi_read_bytes([0x00, 0x01, 0x02, 0x0D, 0x0E, 0x0F]) call.
This last example brings me to the final question, which is: Is it *always* acceptable to read through undefined register addresses like this in order to retrieve all content with a single call? I know of other devices that document such a read being valid (though I think it was I2C that I'm remembering), but I cannot find similar notes for this device.
I'll leave this post here. I'm actually an advanced software engineer with other hardware experience, but new to TDK devices and somewhat to SPI, so I shouldn't have any trouble understanding responses, but I would also appreciate any filling-in-the-basics that it might seem that I've missed.
Thanks,
Steven