Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

SPI communication data transfer rates for LSM6DSO

Hello All,

I am currently attempting to use multiple LSM6DSO IMU(2 units) with nRF52840 on SPI. Is it better to use the 2 IMUs over a single SPI bus(using chip selects and reading one by one) or separate SPI busses and what would be the benefits of the same. What would be the data rate and data loss challenges to look out for?

Below is the data sheet of the IMU for your reference. Do provide comments or suggestions in this regard.

https://www.st.com/resource/en/datasheet/lsm6dso.pdf 

Thanks in advance!!

Parents
  • Hello,

    Not sure if I have a clear recommendation here. But you write SPI, have you considered using I2C instead?

    Typically it's "easier" to queue I2C operations over the same bus, because there is no individual chip select pin, so sharing pins is more straight forward. If you for instance use the i2c api for zephyr in nRF Connect SDK for development, then you can safely call I2C operations from different threads, and if two threads try to use the same i2c resource at the same time, they will just be pending after each other. While if you try to share SPI pins, this will not be as simple, because of the chip select pin that complicates things. I would say both are possible, but using SPI is slightly more complex to share, though if you need to read data fast and frequently, then I guess SPI is the only option in any case due to the increased clock speed (e.g. 8MHz in spi vs 400kHz in i2c).

    Kenneth

Reply
  • Hello,

    Not sure if I have a clear recommendation here. But you write SPI, have you considered using I2C instead?

    Typically it's "easier" to queue I2C operations over the same bus, because there is no individual chip select pin, so sharing pins is more straight forward. If you for instance use the i2c api for zephyr in nRF Connect SDK for development, then you can safely call I2C operations from different threads, and if two threads try to use the same i2c resource at the same time, they will just be pending after each other. While if you try to share SPI pins, this will not be as simple, because of the chip select pin that complicates things. I would say both are possible, but using SPI is slightly more complex to share, though if you need to read data fast and frequently, then I guess SPI is the only option in any case due to the increased clock speed (e.g. 8MHz in spi vs 400kHz in i2c).

    Kenneth

Children
Related