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?
Thanks!
