Last time, I gave you an overview of what you get from I2C, basics like addressing, interface speeds, and a breakdown of pullups. Today, let’s continue looking into I2C capabilities and requirements – level shifting, transfer types, and quirks like combined transfers or clock stretching.
Remember when dead batteries were something you’d just toss in the trash? Those days are long gone, thankfully, and rechargeable battery packs have put powerful cordless tools in the palms of our hands. But when those battery packs go bad, replacing them becomes an expensive proposition. And that’s a great excuse to pop a pack open and see what’s happening inside.
The battery pack in question found its way to [Don]’s bench by blinking some error codes and refusing to charge. Popping it open, he found a surprisingly packed PCB on top of the lithium cells, presumably the battery management system judging by the part numbers on some of the chips. There are a lot of test points along with some tempting headers, including one that gave up some serial data when the battery’s test button was pressed. The data isn’t encrypted, but it is somewhat cryptic, and didn’t give [Don] much help. Moving on to the test points, [Don] was able to measure the voltage of each battery in the series string. He also identified test pads that disable individual cells, at least judging by the serial output, which could be diagnostically interesting. [Don]’s reverse engineering work is now focused on the charge controller chip, which he’s looking at through its I2C port. He seems to have done quite a bit of work capturing output and trying to square it with the chip’s datasheet, but he’s having trouble decoding it.
This would be a great place for the Hackaday community to pitch in so he can perhaps get this battery unbricked. We have to admit feeling a wee bit responsible for this, since [Don] reports that it was our article on reverse engineering a cheap security camera that inspired him to dig into this, so we’d love to get him some help.
Cats are notorious for interrupting workflow. Whether it’s in the kitchen, the garden, or the computer, any feline companion around has a way of getting into mischief in an oftentimes disruptive way. [Robin] has two cats, and while they like to sit on his desk, they have a tendency to interrupt his mouse movements while he’s using his Apple trackpad. Rather than solve the impossible problem of preventing cats from accessing areas they shouldn’t, he set about building a customized tiny trackpad that integrates with his keyboard and minimizes the chance of cat interaction.
The keyboard [Robin] uses is a split ergonomic keyboard. While some keyboards like this might use a standard USB connection to join the two halves, the ZSA Voyager uses I2C instead and even breaks the I2C bus out with a pogo pin-compatible connector. [Robin] originally designed a 3D-printed integrated prototype based on a Cirque trackpad that would clip onto the right side of the keyboard and connect at this point using pogo pins, but after realizing that the pogo pin design would be too difficult for other DIYers to recreate eventually settled on tapping into the I2C bus on the keyboard’s connecting cable. This particular keyboard uses a TRRS connector to join the two halves, so getting access to I2C at this point was as simple as adding a splitter and plugging in the trackpad.
With this prototype finished, [Robin] has a small trackpad that seamlessly attaches to his ergonomic keyboard, communicates over a standard protocol, and avoids any unwanted cat-mouse action. There’s also a build guide if you have the same keyboard and want to try out this build. He does note that using a trackpad this small involves a bit of a learning curve and a larger-than-average amount of configuration, but after he got over those two speed bumps he hasn’t had any problems. If trackpads aren’t your style, though, with some effort you can put a TrackPoint style mouse in your custom mechanical keyboard instead.
In the previous two HID articles, we talked about stealing HID descriptors, learned about a number of cool tools you can use for HID hacking on Linux, and created a touchscreen device. This time, let’s talk about an underappreciated HID standard, but one that you might be using right now as you’re reading this article – I2C-HID, or HID over I2C.
HID as a protocol can be tunneled over many different channels. If you’ve used a Bluetooth keyboard, for instance, you’ve used tunneled HID. For about ten years now, I2C-HID has been heavily present in laptop space, it was initially used in touchpads, later in touchscreens, and now also in sensor hubs. Yes, you can expose sensor data over HID, and if you have a clamshell (foldable) laptop, that’s how the rotation-determining accelerometer exposes its data to your OS.
In modern world of input devices, I2C-HID is spreading, and the coolest thing is that it’s standardized. The standardization means a lot of great things for us hackers. For one, unlike all of those I2C touchscreen controllers, HID-I2C devices are easier to reuse; as much as information on them might be lacking at the moment, that’s what we’re combating right now as we speak! If you are using a recent laptop, the touchpad is most likely I2C-HID. Today, let’s take a look at converting one of those touchpads to USB HID.
I had one of those why-didn’t-I-think-of-it moments this week, reading this article about multiplexing I2C on the ESP32 microcontroller. The idea is so good, and so simple, that it’s almost silly that it’s not standard hacker practice. And above all, it actually helps solve a problem that I’ve got. This is why I read Hackaday every day.
I2C is great in that it lets you connect up multiple devices to a pair of wires using a very bus architecture. Every device has its own address, the host calls them out, and hopefully all other devices keep quiet while just the right one responds. But what happens when you want to use a few of the same sensors, where each IC has the same address? The usual solution is to buy a multiplexer chip.
But many modern microcontrollers, like the ESP32, have an internal multiplexer setup that lets you map the pins with the dedicated hardware peripherals, usually at initialization time. Indeed, I’ve been doing it as an “init” task so long, I never thought to do it otherwise. But that’s exactly the idea behind [BastelBaus]’s hack – if you dynamically reassign the pins, you can do the I2C multiplexing with the chip you’ve got. This should probably work for any other chips that have multiple assignable pins for hardware peripherals as well.
Cool idea, but really simple. Why hadn’t I ever thought of it? I think it’s because I’ve always had this init / mainloop schema in my mind, which for instance the Arduino inherited and formalized in its setup() and loop() functions. Pin mappings go in the init section, right?
So what this hack really amounts to, for me, is a rethinking of what’s static and what’s dynamic. It’s always worth questioning your assumptions, especially when you’re facing a problem that requires a creative solution. Sometimes limitations are only in your mind. Have you had your mind opened recently by a tiny little hack?
Using hardware I2C on an ESP32? Do you need to connect multiple I2C devices with the same address? Normally, you wouldn’t be able to do that without extra parts, but on the ESP32, [BastelBaus] has found a nice hack — just connect your devices to different pins and slightly abuse the ESP32 GPIO muxing, no extra hardware required!
Initially, they tried separating SDA and SCL completely, and after a bit of tinkering, that’s worked out wonders! For this method, [BastelBaus] provides example Arduino code you could easily integrate into your project, and shows logic analyzer captures that demonstrate there’s barely any overhead. Later, they’ve also found out that you could multiplex only one of the pins, specifically, SDA, having the SCL line be common! As far as we see, this could also work out with split SCL, but do let us know if that doesn’t sound right.
Typically, such a problem is solved with an I2C multiplexer, and we’ve highlighted projects with them before. However, this simple method could also work on chips like the RP2040 or even the Raspberry Pi 4 — just a bit more limited, since the GPIO muxing for I2C has less available ports! Also, if you’re not using a chip with such a comfortable GPIO mux and you must use devices with overlapping addresses, check out the comment section under our I2C ecosystem article – there’s a fair few other methods you can use. And, if this method ever malfunctions for you, there’s a bunch of very straightforward ways you could debug your bus!
An oscilloscope can be an expensive piece of equipment, but not every measurement needs four channels and gigahertz sampling rates. For plenty of home labs, old oscilloscopes with CRTs can be found on the used marketplace for a song that are still more than capable of getting the job done, but even these can be overpowered (not to mention extremely bulky). If you’re looking for something even cheaper, and quite a bit smaller, this ESP32 scope from [BojanJurca] might fit the bill.
The resulting device manages to keep costs extremely low, but not without a trade-off. For this piece of test equipment, sampling is done over the I2C bus on the ESP32, which can manage a little over 700 samples per second with support for two channels. With the ESP32 connected to a wireless network, the data it captures can be viewed from a browser in lieu of an attached screen, which also keeps the size of the device exceptionally small. While it’s not a speed demon, that’s more than fast enough to capture waveforms from plenty of devices or our own circuit prototypes in a form factor that can fit even the smallest spaces.
Of course for work on devices with faster switching times, it’s always good to keep a benchtop oscilloscope around. But as far as we can tell this one is the least expensive, smallest, and most capable we’ve come across that would work for plenty of troubleshooting or testing scenarios in a pinch. We’ve seen others based on slightly more powerful microcontrollers like this one based on the STM32 and this other built around the Wio Terminal with a SAMD51, both of which also include built-in screens.
