We're a big user of the BMI160, having chosen it after discovering our previous ST MEMS chip proved too unworkable and unreliable.
Now Bosch is suggesting the BMI270 "for new designs" instead of the BMI160. It's pin and package compatible, which is a good start.
However, the BMI270 requires an 8KB download on every powerup. What is the reasoning there? In an embedded environment you may only have 32KB or 64KB of nonvolatile memory space in the MCU. Demanding that we give up 8KB of that precious memory space is asking a LOT. We cannot afford an extra, external, SPI interfaced memory device just to reprogram the MEMS chip every time... that turns the great, wonderful BMI160 single chip solution into an awkward, expensive, real-estate-consumptive two chip "solution".
Furthermore, many embedded environments (such as ours) cannot be reflashed or updated after manufacture. If there's no way to externally update the 8KB file, what's the point? It's just an extra step that consumes 8KB of memory space, plus the extra firmware to do the work, plus the time loss at powerup, to repeat the exact same procedure every time power is applied.
The 8KB file is downloaded from github so it's not changing. It's the same file for every device so it's not calibration data (which would be device or wafer specific). Why not make this reflashable within the BMI270 and put the default, then-current file in memory at the factory? Then build-and-ship users like us could use it in its default condition, while accessible designs could reflash it later if necessary/desired.
We got to the BMI160 because our previous choice didn't work well. Looks like we might be forced to go elsewhere, again, if the BM160 goes out of production (after just two years!?!) and the BMI270 is the "recommended replacement".
Downloading 8KB of fixed data into the chip with every powerup is an unrealistic burden for many small/embedded designs. There must be one heck of an awesome benefit to offset all of the overhead. Anyone know what it is?
Solved! Go to Solution.
BMI270 had many abundant features, these features didn't need MCU to participate in the algorithm operation, BMI270 directly gave out algorithm output to MCU. So it needed 8KB config file to run algorithm in BMI270.
If you don't need to use any of this feature, you could apply for BMI270 minimal config file do minimize memory footprint in your system. With minimal config file, it allows RAW data access, FIFO data access.
By the way, could we know what is application?
Thank you for your response.
We don't need all of the "new features" of the BMI270. We just need the features of the BMI160. Accelerometer and gyroscope on three axes. We don't want to redesign our PCB and firmware, and pay for an MCU with at least an extra 8KB of program memory, just to support a part that adds no features of value to our product.
We found the BMX160, which appears to be very similar to the BMI160 except with an integrated magnetometer (which we don't need). Is the BMX160 firmware and register compatible with the BMI160 when used with its SPI interface? Is it a drop-in replacement for the BMI160 if you simply ignore the magnetometer?
Waiting for your reply... thanks!
BMX160 was compatible with BMI160 for HW and SW. BMX160 chip ID is not same with BMI160.
You could see BMX160 SW information from the following link, BMX160 SW used BMI160+BMM150 SW.
By default, magnetometer was disabled, you could ignored it if you didn't use it.