A lot of great ICs use I2C to communicate, but debugging a non-working I2C setup can be opaque, especially if you’re just getting started with the protocol/bus. An I2C bus scanner can be a helpful first step in debugging an I2C system. Are all the devices that I think should be present actually there and responding? Do they all work at the bus speed that I’m trying to run? If you’ve got an Arduino or Bus Pirate sitting around, you’re only seconds away from scanning your I2C bus, and answering these questions.
Heat up that iron, you’re going to want to try this one: [Hugatry] is adding hardware to his laptop by tapping into the i2c lines on the memory module. We love this because the penalty for borking memory during the soldering process is much lower than when soldering directly to a motherboard!
Until we watched the video after the break we hadn’t realized that memory modules usually have an i2c EEPROM on them. This is actually a standard called Serial Presence Detect which allows the BIOS to poll the memory and configure automatically. It seems ironic that we knew the Raspberry Pi HAT standard uses this same trick but didn’t know it was on computer memory as well.
Hardware-wise this provides an easy method of soldering your own equipment to the bus. From there it becomes a software hack. Linux, of course, makes this quite easy and that is demonstrated by [Hugatry] with an LM75 temperature sensors. We would like to hear from our Windows and OSX using readers on how the i2c bus can be accessed within those OS’s.
“Instead of an Arduino, he could have done that with a 555 timer.” “Instead of a 555 he could have done that with two transistors.” “Instead of a few transistors, he could have done that with butterflies.” These are quotes from various Hackaday comment threads throughout the years. It seems simplicity is the name of the game here, and if you need a timer chip, how about an 8-pin DIP? This, of course, means an I2C programmable oscillator in the form of an LPC810.
[kodera2t] built this circuit after reaching for a 555 timer a few too many times. It’s a one-chip solution with an ARM core that’s able to generate square waves with 1Hz resolution up to 65536Hz.
The source for this chip is a lot of C, but once it’s in the Flash of the LPC810, this chip becomes a programmable oscillator with an I2C interface. Yes, it’s a one-component solution, no, it’s not a twenty cent chip, but try programming a 555 over I2C.
The videos below show [kodera] playing around with this I2C oscillator, sweeping the frequency from zero to inaudible teenage angst.
[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.
Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.
[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.
There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.
I2C has a seven-bit address space, and you’re thinking “when do I ever need more than 127 devices on a pair of wires?” So you order up some parts only to find that they have one, two, or three user-configurable address pins for any given device type. And you need a bunch more than four or eight capacitive sensor buttons on your project. What do you do?
If you’re reader [Marv G], you think outside the box and realize that you can change the addresses on the fly by toggling address pins high and low with your microcontroller. That is, you can use a single I2C address pin for each device as a chip select signal just like you would have with SPI.
That’s it, really. [Marv G] goes through all of the other possible options in his writeup, and they’re all unsavory: multiple I2C busses, a multiplexer, buying different sensors, or changing micros. None of these are as straightforward as just running some more wires and toggling these with your micro.
We’d even go so far as to suggest that you could fan these chip select lines out with a shift register or one of those 1-of-N decoder chips, depending on how many I2C devices you need to chip-selectify. (We’re thinking 74HC595 or 74HC154.)
Along the way, we found this nice list of the number of address pins for a bunch of common peripherals provided by [LadyAda], in case you don’t believe us about how ubiquitous this problem is. How many devices on that list have one (1!!) address pin?
At the end of his post, [Marv G] asks if anyone else has thought of this chip select trick before. We hadn’t. Here’s your chance to play the smart-ass in the comments.
In the last video I demonstrated a Universal Active Filter that I could adjust with a dual-gang potentiometer, here I replace the potentiometer with a processor controlled solid-state potentiometer. For those that are too young to remember, we used to say “solid-state” to differentiate between that and something that used vacuum tubes… mostly we meant you could drop it without it breakage.
The most common way to control the everyday peripheral chips available is through use of one of the common Serial Protocols such as I2C and SPI. In the before-time back when we had only 8 bits and were lucky if 7 of them worked, we used to have to memory map a peripheral or Input/Output (I/O) controller which means we had to take many control and data lines from the microprocessor such as Data, Address, Read/Write, system clocks and several other signals just to write to a couple of control registers buried in a chip.
Nowadays there is a proliferation of microcontrollers that tend to have built-in serial interface capability it is pretty straightforward to control a full range of peripheral functions; digital and analog alike. Rather than map each peripheral using said data and address lines,which is a very parallel approach, the controller communicates with peripherals serially using but a handful of signal lines such as serial data and clock. A major task of old system design, mapping of I/O and peripherals, is no longer needed.
When an air quality display project needed a display, [Inderpreet] looked into small character-based LCDs. [Inderpreet’s] chosen LCD used an I2C interface, which was new to him. Rather than shy away, [Inderpreet] grabbed his Bus Pirate and dove in!
I2C or Inter-Integrated Circuit serial interfaces are often mentioned here on Hackaday. They generally are easy to use, but as with all things, there are little gotchas which can make the road a bit more bumpy the first time you travel it. One of those things is voltage interfacing – I2C uses bidirectional open drain lines, so interfacing 3.3 V and 5V circuits requires a voltage level shifter circuit designed to handle that requirement. Thankfully in [Inderpreet’s] case, both his TI launchpad target devboard and the LCD used 3.3 volt logic levels.
Before using the TI though, [Inderpreet] wanted to test with the Bus Pirate first. This would allow him to verify the hardware, and to make sure he was correctly using the I2C bus. The Bus Pirate can operate at 3.3V or 5V logic levels, and has on-board programming specific to the I2C bus. Controlling the Bus Pirate is as easy as hooking up a serial terminal program and plugging in a USB cable.
The I2C bus protocol is relatively simple, but can still be confusing to a new user. Each transaction needs an address, read/write bit, and a start command sent in the proper sequence before the data bytes can begin flowing. There are also acknowledge bits which prove that the data bytes are actually being received by the LCD. The Bus Pirate made all this easy, allowing [Inderpreet] to quickly display “Hello” on his LCD module.
The I2C bus is just the tip of the iceberg for the Bus Pirate. If you’re interested in learning more, check it out over at The Hackaday Store!
[via Dangerous Prototypes]