Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.
Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.
The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.
Modern computers do in fact have i2c, if they have any kind of standardized connector for external/additional monitor(s)
It is used for the eeprom in the displays that stores the specifications of supported resolutions and refresh rates, but they only use a single address, so if your computer runs Linux (or probably any of the *nix) flavors, then you have access to that.
Keep in mind it is 5v an often have weak pull up resistors.
There is one I2C bus on the RAM cards for the EEPROMs too – serial presence detect. I’ve used that with some wires soldered to the legs of the IC. Well I wouldn’t do that on my main PC, but I had another one lying around with Linux on it.
Some motherboards expose an SMBus header for expansion. A simple level shifter, keeping to 100kHz clock, and ensuring your code doesn’t reach the 35ms timeout and you’re good to plug in to a simple 4 pin header.
I’m sure they’ve got SPI too, just even less accessible than the I2C on the RAM. And probably harder to use, even if it can be accessed…
most bioses are in a SPI flash chip. Not really exposed but there.
That’s true, on modern computers I2C bus exists in the form of SMBus.
SMBus is basically I2C, just faster, with tighter tolerances. It is used for reading data off temperature sensors and the like, essentially the exact same purpose as a normal I2C bus is.
They do have a lot of I2C. From SMBus to the monitor identification in VGA and up, that’s a lot.
Oh and smbus IS accessible somewhat easily, it is present on the small part of the PCIe connector. Gotta have fun with this one!
Oh and forgot to mention, all sensors in a PC are I2C. Even your laptop’s trackpad has a chance to be I2C (mine on a Dell XPS is), amongst the tens of I2C busses present in a modern laptop.
Careful. They are SMBus, compatible with I2C but different in subtle ways. No high speed data rate, different logic levels, and a bus timeout.
Most laptop battery packs communicate with the laptop itself over 3.3v smbus.
computers do have I2C it is even available on a connector
https://dave.cheney.net/wp-content/uploads/2014/08/ddc.png
Ok interesting. How do you access this functionality? Is there a specific command, applet, or etc that allows for sending I2C specific comms out through these?
n/m found another post explaining. Thanks
under linux you have SMBUS access in userland,using the i2ctools pack from your fav repo. theres a higher level package called lm-sensors that runs in userland too for talking to the boards sensors . Also the gaming motherboards from Asus with the proprietary ROG_EXT connector is i2c/smbus . A word of warning though, dont write to the smbus/i2c bus from linux userland without knowing what device you are writing too, i killed a 300 euro rog motherboard two days ago with just such a method. I was attempting to access the RGB sub layer and ROG_EXT codes for bios failure, dont worry HAD, i am writing up my hack-a-fail for your pleasure, i just need a new pc first . theres a shortage of x470 boards in europe right now.
Not a particularly good design if it can be destroyed that easily.
I believe it’s not meant to be accessed like that.
Older temperature monitoring programs for windows also warned about few cases where they could freeze the system when accessing the i2c/smbus bus.
Tried with a reflashed bios chip?
have erased bios/reset you name it. The board has quite a few points of Bus access for various modern PC buses , bios for example has populated pins for direct bios programming, LPC is well broken out, the ROG_EXT is a sort of gateway and streaming output port (it grabs data off internal SMBUS and puts it out on it’s own dedicated bus) , TPM port is there, there’s modules that connect to the ROG_EXT,this is where my research really lies, the RGB fail on my part was not understanding some things which i now do. Asus software is well known bloat to a PC, my intention is FOSS versions of these without this bloat. I hope to produce a ROG_EXT board that anyone can make, the only device right now is closed source device from Elmor labs for overlay.live , this device itself is just acting as a smbus gateway (no doubt protecting the mobo from people like me) although this is purely a assumption on my part , The mobo access a device on the EXT side at certain address and writes all the current OC values, combined with the USB gadget (which hangs my pc when driver is installed, BSOD) which controls the OC buy acting as a HID keyboard and triggers a AI Tuner macro to apply the final overclock, again not working on my hardware, not hardware issue but poorly updated drivers/firmware in order to sell another same..but different product. Anyhoo, the rest i will add to my write up for those who would follow into my deep look into x470 firmware/UEFI/supporting chipset.
https://hackaday.com/2014/06/18/i2c-from-your-vga-port/
Good effort! The bus pirate does both and more besides though.
I just bought a bus pirate – just what I need at the moment.
The buspirate is one of the best tools ever made. i’ve fixed pc’s , phones, tv’s , 2 channel DSO all using the buspirate. I cant wait for gen two buspirate (stm32 ) , i’ve beem following the dangerous prototypes forums for the gen 2 chat. the picchip had a advantage of re-routing signals that the stm32 does not, however a addition of a cpld (or soon fpga) allows a little more flexibility in that area.
Long live the BusPirate !!!
Or you could just use a Raspberry pi, which has both SPI and I2C, library drivers for most languages, and these days, fairly decent performance (you won’t die waiting…just be annoyed). Kinda on the small and inexpensive side, and not much of a hack since it just kinda works, is easy to learn from examples, and is documented all over.
If you wanted to do things the hard way and call it a hack, you could power it off a USB port and use a separate USBserial dongle for the pi built in uart and write a buncha code…I just plug in a monitor and keyboard….
Grabbing some little SBC has been my usual solution for this sort of thing, but I can see where this tool can win on convenience. Just the difference in wiring complexity between one USB device vs. a Pi, USB-UART, and logic analyzer could make it worthwhile.
What about interacting with software that only runs on x86_64 ????? Not very Rpi friendly at present.
Thankfully the amount of software that’s architecture locked and requires i2c or smbus is virtually nil.
I’d be more concerned about lack of level shifter/buffer
I love the screen idea.
How about a $3.50 NodeMCU?
Hi
I tried to build one from scratch but I am compleately stuck compiling and uploading the strange firmware. Unfortunately I found out way too late that it is using forth and I have no idea how to compile the sources.
Has anyone managed to do that an is willing to help me ?
you still interested? ofc five years too later, but who knows if you still have the hardware laying on the shelf