[Dan], admirably rose to the occasion when his son wanted a new toy. Being a dedicated father — and instead of buying something new — he took the opportunity to abscond to his workbench to convert a Wiimote Nunchuck into a fully wireless controller for his son’s old r/c car — itself, gutted and rebuilt some years earlier.
Unpacking the nunchuck and corralling the I2C wires was simply done. From there, he combined a bit of code, an Arduino pro mini, and two 1K Ohm resistors to make use of an Aurel RTX-MID transceiver that had been lying around. Waste not, want not.
A TI Stellaris Launchpad is the smarts of the car itself, in concordance with a TB6612FNG motor controller. The two Solarbotics GM9 motors with some 3D printed gears give the car some much needed gusto.
A few weeks back, we talked about the no-nos of running I²C over long wires. For prototyping? Yes! But for a bulletproof production environment, this practice just won’t make the cut. This month I plucked my favorite solution from the bunch and gave it a spin. Specifically, I have put together a differential I²C (DI²C) setup with the PCA9615 to talk to a string of Bosch IMUs. Behold: an IMU Noodle is born! Grab yourself a cup of coffee and join me as I arm you with the nuts and bolts of DI²C so that you too can run I²C over long cables like a boss.
What’s so Schnazzy about Differential Signals?
There’s a host of ways to make I²C’s communication lines more noise resistant. From all of the choices we covered, I picked differential signals. They’re simple, fairly standardized, and just too elegant to ignore. Let’s take a moment for a brief “differential-signals-101” lecture. Hopefully, you’re already caffeinated! Continue reading “An Introduction to Differential I²C”→
Economies of scale and mass production bring us tons of stuff for not much money. And sometimes, that stuff is hackable. Case in point: the $5 Sonoff WiFi Smart Switch has an ESP8266 inside but the firmware isn’t very flexible. The device is equipped with the bare minimum 1 MB of SPI flash memory. Even worse, it doesn’t have the I2C ports extra pins exposed so that you can’t just connect up your own sensors and make them much more than just a switch. But that’s why we have soldering irons, right?
The HC-SR04 sonar modules are available for a mere pittance and, with some coaxing, can do a pretty decent job of helping your robot measure the distance to the nearest wall. But when sellers on eBay are shipping these things in ten-packs, why would you stop at mounting just one or two on your ‘bot? Octosonar is a hardware and Arduino software library that’ll get you up and running with up to eight sonar sensors in short order.
Octosonar uses an I2C multiplexer to send the “start” trigger pulses, and an eight-way OR gate to return the “echo” signal back to the host microcontroller. The software library then sends the I2C command to select and trigger a sonar module, and a couple of interrupt routines watch the “echo” line to figure out the time of flight, and thus the distance.
Having two sonars on each side of a rectangular robot allows it move parallel to a wall in a straightforward fashion: steer toward or away from the wall until they match. Watch the video below for a demo of this very simple setup. (But also note where the robot’s 45-degree blind spot is: bump-bump-bump!)
The LTC4316 is something special. It’s an I²C address translator that changes the address of a device that would otherwise conflict with another on the same I²C bus. Not a hack? Not so fast. Exactly how this chip does this trick is clever enough that I couldn’t resist giving it the post it rightfully deserves.
What’s so special? This chip translates the address on-the-fly, making it transparent to the I²C protocol. Up until this point, our best bet for resolving address collisions was to put the clashing chip on a separate I²C bus that could be selectively enabled or disabled. In that department, there’s the PCA9543 and PCA9547 demultiplexers which we’ve seen before. Both of these devices essentially act like one-way check valves. To address any devices downstream, we must first address the multiplexer and select the corresponding bus. While these chips resolve our address collision problems, and while there’s technically a way to address a very large number of devicesif we’re not time-constrained, the control logic needed to address various bus depths can get clunky for nested demultiplexers.
What’s so classy about the LTC4316 is that is preservers simplicity by keeping all devices on the same bus. It prevents us from having to write a complicated software routine to address various sections of a demultiplexed I²C bus. In a nutshell, by being protocol-transparent, the LTC4316 keeps our I²C master’s control logic simple.
If you’re reading these pages, odds are good that you’ve worked with I²C devices before. You might even be the proud owner of a couple dozen sensors pre-loaded on breakout boards, ready for breadboarding with their pins exposed. With vendors like Sparkfun and Adafruit popping I²C devices onto cute breakout boards, it’s tempting to finish off a project with the same hookup wires we started it with. It’s also easy to start thinking we could even make those wires longer — long enough to wire down my forearm, my robot chassis, or some other container for remote sensing. (Guilty!) In fact, with all the build logs publishing marvelous sensor “Christmas-trees” sprawling out of a breadboard, it’s easy to forget that I²C signals were never meant to run down any length of cable to begin with!
As I learned quickly at my first job, for industry-grade (and pretty much any other rugged) projects out there, running unprotected SPI or I²C signals down any form of lengthy cable introduces the chance for all sorts of glitches along the way.
I thought I’d take this week to break down that misconception of running I²C over cables, and then give a couple examples on “how to do it right.”
The Bus Pirate is one of our favorite tool for quick-and-dirty debugging in the microcontroller world. Essentially it makes it easy to communicate with a wide variety of different chips via a serial terminal regardless of the type of bus that the microcontroller uses. Although it was intended as a time-saving prototyping device, there are a lot of real-world applications where a Bus Pirate can be employed full-time, as [Scott] shows us with his Bus Pirate data logger.
[Scott] needed to constantly measure temperature, and the parts he had on hand included an LM75A breakout board that has a temperature sensor on board. These boards communicate with I2C, so it was relatively straightforward to gather data from the serial terminal. From there, [Scott] uses a Python script to automate the process of gathering the data. The process he uses to set everything up using a Raspberry Pi is available on the project site, including the code that he used in the project.
[Scott] has already used this device for a variety of different projects around his house and it has already proven incredibly useful. If you don’t already have a Bus Pirate lying around there are a few other ways to gather temperature data, but if you have an extra one around or you were thinking about purchasing one, then [Scott]’s project is a great illustration of the versatility of this device.