Dear all, For a personal project, I am looking into upgrading some firmware for the BMI160 to the BMI270 (integrated on a PCB). There, I am struggling with reading the correct CHIP_ID of the BMI270 over SPI communication. To test my hypotheses, I turned to COINES and the App2.0 board with shuttle boards of the two sensors and had an in-depth look at the differences in the start-up procedure. I found out that I can read the CHIP_ID of the BMI270 with minor alterations to the bmi160_read_chip_id.c script and some of the functions it calls. The most interesting insight came from the differences in the employed *get_regs() functions, which also caused a big question as to why it even works in the case of the BMI160: To read from registers of the BMI270, bmi2_get_regs() is used. In SPI mode, this function receives data that is one byte longer than the relevant data, that one byte is referred to as the dummy_byte. To read from registers of the BMI160, bmi160_get_regs() is used. This function has no notion of a dummy_byte and when trying to use it to read registers from a BMI270 it actually returns zeros, i.e., the dummy_byte. So my question is: How come the SPI communication of the two sensors has such a fundamental difference? From the datasheets, I followed that both sensors receive a dummy_byte over SDO, but only the code for the BMI270 reflects this. Moreover, I thought this was a fundamental concept of SPI, but since I am rather new to this world, I am happy for corrections to this view. Lastly, if there is such a thing like a dummy_byte in the SPI communication with the BMI160, how is it handled by bmi160_get_regs()? I am very grateful for all pointers and help! Cheers, Nic EDIT: Just realized that the latest version of the BMI160_driver incorporates the notion of a dummy_byte. However, the latest version of COINES still features the code I linked above without any notion of a dummy_byte, so my question as to why it works remains.
... View more