The #enshittification of I2C sensors is happening too. Bosch has been a frequent offender, but they're not the only ones. The sensor powers up with no internal firmware (an I2C paperweight). You have to load a proprietary binary blob into the sensor before it works. This blob is controlled under a restrictive license agreement. Luckily there is still some competition in this sector, but innovative/new parts try this trick.
cc @pluralistic
@fast_code_r_us Is this to avoid the cost of internal flash or something more deviant?
@trcwm It's possible, but I see it as a way to prevent reverse engineering of the I2C protocols by forcing you to use their licensed libraries. Sensor vendors are trying to create "smart" sensors to extract more profit and stand out from their competition. I personally see it as a strong negative signal to not use their parts.
@fast_code_r_us @trcwm My 2 cents (from a semicon background) : sensors may use non-standard processes, and RAM can be made in nearly all processes. Flash can't.
So it's either RAM+blob or ROM. ROM means you freeze the firmware month before release, can't do fixes if an issue appear after releases, and it makes releasing "custom fw" for customers with special needs expensive. So RAM + blob is a good option sometimes.
At Semtech we used such blobs for some advanced radios. The blob had the same BSD license as the driver we provided publicly.
Forcing user to use a restrictive driver seems like a dick move.
