This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPI register-based read

I am using the nRF52840 DK to read data from an IMU sensor (STm LSM9DS1 9DOF). Like most sensors, you transmit the register number first (on MOSI), then continue clocking and the sensor returns the value.

I have based my code on the SDK v15.3.0 example "SPI Master". The sensor-specific code is from STm's "STMems Standard C Drivers" library. It works fine, but needed some tweaking.

The sensor's MISO line remains high impedance until the register has been sent. However, the SPI Master Driver functions returns data starting with that very first write, which is undefined data. I can do an initial write (to set the register) and discard the returned byte, and then further reads to get the register value(s), but this seems clumsy -- there is a noticeable delay between the initial register write, and the subsequent data read.

The STm library assumes all reads are just the selected register data, and doesn't account for that initial undefined data byte.

Is it possible to configure the SPI Master functions to always discard the initial returned byte, rather than having to do the two separate writes? Am I missing something in the SPI Master Library?

Parents
  • Some quick background: Typically one setup a TX and RX buffer of the same length, then you fill up the TX buffer with what data you want to send (e.g. the first byte(s) is typically a command byte that tell if it's a read/write and the register to access), the length of the transfer equal the size of the complete transfer (command byte(s) + data). Then after the transfer you analyze the RX data as you see fit, in your case you should ideally just ignoring the first byte(s) in the buffer. No need to do this in two transfers unless you are very tight on RAM usage. Ideally one could wish some kind of offset of data written to the RX buffer depending on where the actual data start etc, but it would just complicate/over engineer the hardware, so it's not supported.

    To answer/solve your question: I don't see any easy solution to your problem, other than you manipulate the buffers in some way, such that the underlying spi transfer will see a rx buffer that start a fixed number of bytes ahead of the buffer seen by the library.

    Best regards,
    Kenneth

Reply
  • Some quick background: Typically one setup a TX and RX buffer of the same length, then you fill up the TX buffer with what data you want to send (e.g. the first byte(s) is typically a command byte that tell if it's a read/write and the register to access), the length of the transfer equal the size of the complete transfer (command byte(s) + data). Then after the transfer you analyze the RX data as you see fit, in your case you should ideally just ignoring the first byte(s) in the buffer. No need to do this in two transfers unless you are very tight on RAM usage. Ideally one could wish some kind of offset of data written to the RX buffer depending on where the actual data start etc, but it would just complicate/over engineer the hardware, so it's not supported.

    To answer/solve your question: I don't see any easy solution to your problem, other than you manipulate the buffers in some way, such that the underlying spi transfer will see a rx buffer that start a fixed number of bytes ahead of the buffer seen by the library.

    Best regards,
    Kenneth

Children
Related