Which communication protocol or open standard in software do you wish was more common or used more?
Which communication protocol or open standard in software do you wish was more common or used more?
Whether you're really passionate about RPC, MQTT, Matrix or wayland, tell us more about the protocols or open standards you have strong opinions on!
You're viewing a single thread.
I'd love to see more adoption of... I2C!
Bazillions of motherboards and SBCs support I2C and many have the ability to use it via GPIO pins or even have connectors just for I2C devices (e.g. QWIIC). Yet there's very little in the way of things you can buy and plug in. It feels like such a waste!
There's all sorts of neat and useful things we could plug in and make use of if only there were software to use it. For example, cheap color sensors, nifty gesture sensors, time-of-flight sensors, light sensors, and more.
There's
lmsensorswhich knows I2C and can magically understand zillions of temperature sensors and PWM things (e.g. fan control). We need something like that for all those cool devices and chips that speak I2C.I2C is a bit goofy though. As a byproduct of being an undiscoverable bus you basically just have to poke random addresses and guess what you're talking to. The fact lmsensors i2c detection works as well as it does is a miracle. (Plus you get the neat issue where even the act of scanning the bus can accidentally reconfigure endpoints)
Yeah, the lack of proper discoverability on i2c truly sucks. You have to just poke random addresses and hope for the best to see if an i2c device exists on the bus. It's a great standard but I wish it would get updated with some sort of plug and play autodetection feature. Standardized device PID/VID system like USB and PCI would be acceptable or a standardized register that returns a part string. Anything other than blindly poking registers and hoping you're not accidentally overvolting the CPU or whatever because the register on your expected device overlaps with the overvolt the CPU register on the same address of a different device.
I'm curious. There was some i2c connected memory devices before. Is there some forgotten spec that allows for a flexible device lookup / logging capability. Something that acts like device tree but stays specific to the bus. It wouldn't be practical for a lot of applications but I could see it being useful for some niche stuff.
If you have an unused VGA port, you can use the DDC pins for I2C. Be sure to add ESD protection if you do this. An I2C isolator would be even better.
I2C is really not meant to be used over cables. It has a very limited common mode input voltage range and it can't handle much capacitance on the bus.
Except that in the case of VGA (and DVI, HDMI, and DisplayPort) the i2c interface is intended for use over the cable. All of those ports have a pair of i2c pins and corresponding wires in their cables. The i2c interface is used for DDC/EDID which is how the computer can identify the capabilities and specifications of the attached display. DDC even provides some rarely-used control functionality. Probably the most useful of which is being able to control the brightness of the display from software. I use the ddcci module on Linux and it lets me control my desktop monitor brightness the same way a laptop would, which is great. I have no idea why this isn't widely used.
Edit:
This i2c interface is widely used to control the lighting on modern graphics cards that have RGB lighting. We've spent a lot of time reverse engineering these chips and their i2c protocols for OpenRGB. GPU chips usually have more i2c buses than the cards have display connectors, so the RGB chip is wired to one of the unused buses. I think AMD GPUs tend to have 8 separate i2c buses but most cards only use 4 or 5 of them for display connectors. There is also an i2c interface present on RAM slots normally used for reading the SPD chip that stores RAM module specifications, timings, etc. This interface is also used for RAM modules with controllable RGB lighting.