It’s not much of a stretch to assume that the majority of Hackaday readers are at least familiar with I2C. In fact, there’s an excellent chance that anyone who’s ever done more with an Arduino than blink the onboard LED has at one time or another used the serial communication protocol to talk to a sensor, display, or other external gadget. Of course, just because most of us have used it in a few projects doesn’t mean we truly understand it.
If you’re looking to brush up on your I2C knowledge, you could do worse than to follow the guide [András Tevesz] recently wrote up. With a title like Hardware Hacking 101: E01 I2C Sniffing, How to Listen to Your Arduino’s I2C Bus, you know you’re in for a good time. While the document is arguably geared more towards security researchers than electronic hobbyists, the concepts presented can be useful even if you’re just trying to debug your own projects.
While you could certainly adjust the hardware used to fit whatever you’ve got kicking around the parts bin, the setup [András] details uses a BeagleBone Black as the master device that communicates with an Adafruit Trinket and Arduino over I2C. He provides code for all three devices, and when everything is running as it should be, the microcontrollers will blink their LEDs in time with signals being sent out over the bus by the BeagleBone.
This, in itself, has educational value. Sure most of us have used turn-key I2C devices, but how many have actually made one? But beyond that, it also gives you a simple and user-controllable bus to poke around in. [András] hooks up a Saleae logic analyzer (never fear, that $10 USD one you got on eBay will work just as well) and studies the actual messages as they go over the wire. If you’ve ever wanted to take a close look at the nuts and bolts of this ubiquitous protocol, it’s a great way to get your foot in the door. While on the subject, be sure to check out the excellent guide our own [Elliot Williams] wrote up back in 2016.
[Thanks to zh4ck for the tip.]
Even though I2C may seem pretty simple at first, it too has all sorts of aspects to it that many people (hobbyists?) seem to not know about, like e.g. I’ve seen quite a few projects where the developer didn’t know that you can send a command to all the connected I2C-devices at once instead of having to loop through each and every one. One can do this by I2C general call command, ie. by sending a command to address 0x0.
On a similar vein, I’ve seen people coming up with all sorts of schemes for cutting power to all connected I2C-devices in order to reset them, whereas they could instead just send a general call command 0x06, ie. software reset, on the bus to reset them. If one can’t send the general call because the bus is being held busy by some device, pulsing the clock-line 9 times (or more?) will possibly do the trick of releasing the bus.
Wow I never knew any of that and I use the i2c bus regularly and write all my own drivers, but really how useful is sending the same command to every device since all devices seem to use different commands and everything, it may be useful if you are trying to send the same command to many of the same device like servo drivers that you can change the address of but other than that it may cause unwanted effects if multiple devices connected to the bus interpret that command to mean a different thing. If I’m wrong please let me know, I just want to learn.
Obviously you’ll need to know what devices you have connected to the bus; just randomly sending commands to them all would be pointless, if you didn’t actually know what would happen.
That said, if you e.g. had one master controlling multiple sub-masters, you could send a bus-wide command to them all to start processing something that may take a while to do without having to loop through each one separately. Or if you e.g. had a whole bunch of sensors on multiple buses; having to only loop through all the buses instead of all the sensors on all the buses will save a lot of time and power.
You seem to only be thinking in terms of having a single bus and how having all sorts of different devices connected to the bus could cause havoc, but given how few wires I2C requires and how easy it is to drive, grouping a whole bunch of similar devices together and having multiple buses instead, one for each group, can make an otherwise sprawling design quite manageable and will allow to take advantage of these general call commands as well in a very efficient manner.
I definitely miss a like button
I think I sometimes dream in i2c, the amount of hours I’ve watched it on a logic analyzer..
but if you really want to get the hang of it write your own i2c master (which I’ve done on a number of devices) – it’s surprising how well it can work in software, and then you can have multiple masters on the same chip which is often useful..
Even the first image on the original blog post is plain wrong. Multiple pull-up resistors connected to every single slave device on the IIC bus will stop the bus from working.
As per specs, 3mA (Standard Mode and Fast Mode) and 400 pF are allowed. I tried to avoid a first comment, glad you took it upon yourself.
“CUJO AI Engine is built on billions of real-world data points. It effectively detects and blocks malicious activity by unobtrusively observing how data moves in the network.”
Has anyone wondered whether the article “tip” wasn’t just an operation to analyze HaD…
> Has anyone wondered whether the article “tip” wasn’t just an operation to analyze HaD…
It’s a blog post on a commercial security site. They’re clearly digging in to a communications protocol often ignored but which can (if implemented badly) impact whatever it’s connected to.
You make it sound like they setup a fake website.