looking at bmi08a_get_synchronized_data code, I noticed that synchronous accelerometer data fetch is split into two different transactions, the first for x and y coordinates, the second for z.
I then tried to group the two transactions into a single read covering all required addresses, including the range between BMI08X_REG_ACCEL_GP_0 and BMI08X_REG_ACCEL_GP_4. Longer payload, but an SPI transfer saved.
Doing this I still get correct values for x and y, but z fixed to zero. Should I then assume as mandatory to have a dedicated read starting at BMI08X_REG_ACCEL_GP_4 (z address), or it can be included in a longer transaction without side effects?
According to BMI088 datahseet in the attached screenshot, the register address of accel z-axis (0x27) is not consecutive with x and y axis (0x1E). So you cannot read the 3 axis synchronized accel data in the one read.
thanks for your answer.
From my previous message:
I then tried to group the two transactions into a single read covering all required addresses, including the range between BMI08X_REG_ACCEL_GP_0 and BMI08X_REG_ACCEL_GP_4
As said, I know that x/y and z are located at different addresses. My question was to understand why it looks we can not read all locations from x/y to z in a single SPI transaction, a common practice when accessing a continuous memory/register space through SPI/I2C. The transfer properly completes, but I get corrupted z coordinate.
In my specific case, the overhead of a new SPI transfer is bigger than the penalty from the increased payload coming from all intermediate registers between x/y and z, so having the possibility to read accelerometer data in a single shot would be really an improvement.
Sorry that the BMI088 accel synchronized data register addresses for x/y and for z are not next to each other so that you can read all x/y/z data in one SPI transaction. This is because the limit of available registers inside BMI088 accel.