boschsensortec / bmi270_sensorapi Goto Github PK

This library seems to have hardcoded values for all the FIFO frame lengths, so if I set the auxiliary sensor read length to anything other than 8 bytes the data is incorrectly interpreted.

The work-around is just to set the read length to 8 bytes.

I'm using osDelay function since I'm using FreeRTOS to run my application.
So in the bmi API I implemented my delay as below
void coines_delay_usec(uint32_t delay_us){ uint32_t ticks = (uint32_t)(delay_us/1000); osDelay(ticks); }

But it's actually not working, I'm getting an error right after executing this line:
rslt = bmi270_context_init(&bmi2_dev);

Indeed rslt value turn '0xfd' instead of '0x00'

When I try with a simple HAL_Delay() in a No-OS application it works fine.
My OS tick rate is 1000Hz.

Line 4691 -

  if ((sens_cfg[loop].type != BMI2_ACCEL) || (sens_cfg[loop].type != BMI2_GYRO) ||
                (sens_cfg[loop].type != BMI2_TEMP) || (sens_cfg[loop].type != BMI2_AUX))

GCC correctly detects this as a bug
error: logical 'or' of collectively exhaustive tests is always true [-Werror=logical-op]

I assume the ||'s are supposed to be && ?

Im using this code example:
https://github.com/boschsensortec/BMI270-Sensor-API/blob/master/bmi270_examples/fifo_watermark_headerless_mode/fifo_watermark_headerless_mode.c#L67

and i have observed that when a too high fifo readout length is given to bmi2_read_fifo_data(...) it does request the whole length in one read, breaking the limitation limit given in bmi2_dev.read_write_len.

Hi there,

I'm working on some code using the FIFO of the BMI270 and ran into an issue because the number of available data frames of both same configured parts acc and gyro do not show the same value.
I now tried the official examle fifo_full_headerless_mode.c and run into the same issue:

Iteration : 2
FIFO data bytes available : 1992
FIFO data bytes requested : 1992
FIFO accel frames requested : 170
FIFO accel frames extracted : 165
FIFO gyro frames requested : 170
FIFO gyro frames extracted : 166

There are e.g. 166 extracted gyro frames, but only 165 gyro frames. With each iteration there's one frame difference.
But I think it should be the same amount of data.
As example: If both (gyro and acc) are set to e.g. 25Hz I'd assume to get 25 frames for each one per second, which doesn't seem to be the case.

So what am I doing wrong or what could I improve to get the same amount of data for both, gyro and acc?

This is dependency to run some examples. Where are the files?

Hi,

We have go through the datasheet to figure out the explanation regarding the step counter params but with no lucky. Could you provide some explanation regarding the param_1 ~ param_25 and we would like to explore the way to twist the device to fit in our using scenarios.

Thanks!

BMI270 fast offset compensation calls are very slow due to their current design

• perform_gyro_foc performs 128 loops with 50 ms delay each (delay chosen because ODR set by set_gyro_foc_config is 25Hz / 40 ms), which results in 6,4 seconds minimum duration
• perform_accel_foc performs 128 loops with 20 ms delay each (delay chosen because ODR set by by set_accel_foc_config is 50 Hz / 20 ms), which results in 2,56 seconds minimum duration

This result in roughly 10 seconds to perform FOC on those two sensors, which is slow for a factory.

My questions are:

1. Why those "slow" ODR have been chosen for FOC actions?

   • Are low ODR wanted to operate a low-pass filter for a more accurate FOC
   • Were they chosen for wide hardware compatibility, in order to not require high speed buses and processor for this function?

2. What would be the issue to speed it up?

   • Ideally, enabling FIFO and a higher ODR may collect 128 samples much faster
   • Simply a higher ODR / smaller delays, without a FIFO which may be cumbersome to implement, may lead to shorten FOCs

3. (extra) What would be the issue to not perform FOC at all?

   • Well, if FOC must be as slow to be good, is there a known worst offset shift to expect after BMI270 chip is soldered?

bmi270_defs.h:

  /*! @name BMI2 configuration load status */
  #define BMI2_CONFIG_LOAD_SUCCESS                  UINT8_C(1)

  /******************************************************************************/
  /*! @name       Macro Definitions for internal status                 */
  /******************************************************************************/
  #define BMI2_NOT_INIT                             UINT8_C(0x00)
  #define BMI2_INIT_OK                              UINT8_C(0x01)
  #define BMI2_INIT_ERR                             UINT8_C(0x02)
  #define BMI2_DRV_ERR                              UINT8_C(0x03)
  #define BMI2_SNS_STOP                             UINT8_C(0x04)
  #define BMI2_NVM_ERROR                            UINT8_C(0x05)
  #define BMI2_START_UP_ERROR                       UINT8_C(0x06)
  #define BMI2_COMPAT_ERROR                         UINT8_C(0x07)
  #define BMI2_VFM_SKIPPED                          UINT8_C(0x10)
  #define BMI2_AXES_MAP_ERROR                       UINT8_C(0x20)
  #define BMI2_ODR_50_HZ_ERROR                      UINT8_C(0x40)
  #define BMI2_ODR_HIGH_ERROR                       UINT8_C(0x80)

bmi2.c:

  int8_t bmi2_write_config_file(struct bmi2_dev *dev)
  {
      ...
      
          /* Write the configuration file */
          rslt = write_config_file(dev);
          if (rslt == BMI2_OK)
          {
              /* Check the configuration load status */
              rslt = bmi2_get_internal_status(&load_status, dev);
  
              /* Return error if loading not successful */
              if ((rslt == BMI2_OK) && (!(load_status & BMI2_CONFIG_LOAD_SUCCESS)))    //**bug here???!!!!**
              {
                  rslt = BMI2_E_CONFIG_LOAD;
              }
          }
  
      ...
      
      return rslt;
  }

As we can see the description of register INTERNAL_STATUS above, it's not hard to know that the "if condition" should be:

  /* Return error if loading not successful */
  if ((rslt == BMI2_OK) && ((load_status & 0x0f) != BMI2_INIT_OK))  //correction!!!
  {
        rslt = BMI2_E_CONFIG_LOAD;
  }

Thanks!!!

I want to use the BMI270 to implement attitude calculation, including static, sitting, lying and walking. I see that this library contains a part. I want to ask how to recognize sitting and lying?

The line
/* Wait till ASIC is initialized */ dev->delay_us(150000, dev->intf_ptr);

was removed from write_config_file in bmi2.c, this doesn't work on my installation. Adding the wait back does.