Before blindly messing with i2c, note that the warnings and confirmation prompts in the various i2c tools (i2cdetect, i2cdump, etc.), which the author is bypassing here with the -y flag, really are there for a reason. i2c devices can be quite fickle, and even commands that seem like they should be purely read-only (e.g. i2cdump) can have damaging effects (like rendering your laptop’s built-in display inoperable, as I’ve discovered first-hand).
I’ve got a temperature sensor with loadable firmware which uses a read from a specific address as a signal to wipe the firmware and start reading the next one. Yeah, please watch out with those commands.
Why would anyone design something like that? It’s just…mindboggling?
I think it’s a bug. It’s documented as doing the reset on write to that address, but read does the same.
Thanks for the feedback! I’ll add a warning in my article.
I love this because I went through exactly the same thing last month when working on getting the accelerometer and touchscreen working in a “Maix Amigo” (for a toy project).
Very nice article! I’ve always been curious about the process for writing kernel drivers. Figuring out how the hardware works has always seemed like magic to me, so knowing that these i2c tools exist is useful (even if they are a dangerous to use blindly).