ACCESS.bus: The Forgotten USB Competitor
15 comments
·March 2, 2025nyanpasu64
duskwuff
I2C is also extremely common as a low-speed peripheral bus in electronic devices - some common applications are:
- Small EEPROMs, often used for configuration data or small firmware blobs
- MEMS sensors (accelerometers, gyroscopes, etc)
- Small LCD/OLED displays (e.g. 128x64)
- Configuration ports on devices which use other busses for bulk data (e.g. display drivers, audio codecs, etc).
mmastrac
The I2C part is something of an implementation detail -- it's only _really_ guaranteed to work as an EEPROM interface. It's usable on a lot of platforms, but again, not a guarantee.
extraduder_ire
I use ddcutil all the time on linux to set my monitor brightness without needing to fiddle with the OSD.
pabs3
The ddcutil folks also have a great GUI btw:
https://www.ddcutil.com/#ddcui
Also, if you have ddcci-driver-linux installed, then the KDE desktop lets you adjust monitor brightness from the UI. Eventually Linux upstream might get the same functionality as the out-of-tree module.
nyanpasu64
In my experience the KDE desktop lets you set monitor brightness from the UI... and on Wayland it happens even if you don't ask it to (https://bugs.kde.org/show_bug.cgi?id=494497). You can turn it off by "setting the `POWERDEVIL_NO_DDCUTIL=1` environment variable in PowerDevil as described in its README file: https://invent.kde.org/plasma/powerdevil/-/blob/master/READM..."
crote
You can even use the I2C bus to attach a second (tiny) display, see for example https://www.youtube.com/watch?v=8UbVgUFfN8U
atoav
HDMI is an absolutely unhinged standard. I run the mediatec department at a university and the amount of things that can go wrong with HDMI is absolutely astonishing, when 99,9% of people at best what the digital equivalent of analog video /audio connections.
The best thing was certain macbooks not working at a certain input. It the turns out HDCP was at fault, which is basically DRM for HDMI.
ahlCVA
My favorite bit of alternate history computer interface standards is UPAMD (https://en.wikipedia.org/wiki/Universal_Power_Adapter_for_Mo...) - essentially what USB-C/USB-PD ended up being but using CAN for communication and a pogo-pin-based connector.
theamk
This article mentions one downside of ACCESS.bus (low speed), but misses another big one: it's a shared bus. Meaning that any misbehaving/buggy device can bring entire bus (and all devices on it) down, or slow it down significantly (via SCL stretching)
Compare this to USB, which has fixed timing (once you get the bus, you have to respond in time or release bus without sending anything). Moreover, all USB traffic is sent via hubs - so if device is misbehaving, hubs can cut it off without affecting the rest. The spec even has provisions for cutting off the power to misbehaving device, but most cheap hubs do not implement this.
extraduder_ire
A major disadvantage of using something based on i2c for computer peripherals is being unable to connect two devices with the same ID at a time.
xattt
Memory unlocked: the family ViewSonic 17PS-2 had an Access.bus connector on the back.
I couldn’t find any info back in the day beyond that it was I2C-based, but appreciate being able to connect the dots now.
linwangg
[dead]
VGA/DVI/HDMI ports have an I2C interface (though DP tunnels I2C over AUX), which is normally used to read EDID information from monitors and control brightness, but on Linux (not Windows) you can control it as a general-purpose I2C bus, dump and even rewrite EEPROMs placed on the monitor bus. In theory you could even hook up a Nunchuk or Classic Controller to a display output (with level shifters if you want to run the Nunchuk at 5V off a 3.3V bus), and write a Linux driver to communicate with the peripheral and expose it as a game controller.