Bus Pirate Commandeers I2C

February 7, 2017 by Bryan Cockfield 19 Comments

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.

PURE Modules Aim To Make Prototyping Easier

December 25, 2016 by Elliot Williams 15 Comments

[Sashi]’s PURE modules system wants your next wireless microcontroller and sensor module project to be put together using card-edge connectors. But it’s a lot deeper than that — PURE is an entire wireless gadget development ecosystem. Striking a balance between completeness and modularity is very difficult; a wire can carry any imaginable electronic signal, but just handing someone a pile of wires presents them a steep learning curve. PURE is at the other end of the spectrum: everything is specified.

So far, two microcontroller options are available in the system, the nRF52 series and TI’s CC2650. Both of these run the Contiki OS, so it doesn’t matter which of these you choose. Wired data is all transmitted over I2C and connects up via the previously-mentioned card-edge connectors. On the wireless side, data transport is handled through an MQTT broker, using the MQTT-sn variant which is better suited to small radio devices. At the protocol layer everything uses Protocol Buffers, Google’s newest idea for adding some structure to the data.

Continue reading “PURE Modules Aim To Make Prototyping Easier” →

DIY I2C Devices With ATtiny85

November 7, 2016 by Elliot Williams 31 Comments

[Pawel] has a weather station, and its nerve-center is a Raspberry Pi. He wanted to include a light sensor but the problem is, the Pi doesn’t have a built-in ADC to read the voltage off the light-dependent resistor that he (presumably) had in his junk box. You can, of course, buy I2C ADC chips and modules, but when you’ve already got a microcontroller that has ADC peripherals on board, why bother?

[Pawel] wired up a tremendously simple circuit, downloaded some I2C slave-mode code, and added an LED for good measure. It’s all up on GitHub if you’re interested.

cropped_shot_2016-10-21-112958 — Bright by Day, Dark by Night!

We’re covering this because we rarely see people coding for I2C slave devices. Everyone and their mom uses I2C to connect to sensors, for which the Arduino “Wire” library or “i2c-tools” on the Pi do just fine. But what do you do when you want to make the I2C device? [Pawel]’s project makes use of TinyWireS, a slave-mode SPI and I2C library for AVR ATtiny Arduino projects.

Here, [Pawel] just wanted a light sensor. But if you’re building your own devices, the sky is the limit. What’s the most esoteric I2C sensor that you can imagine? (And is it really the case that we haven’t seen an I2C slave device hack since 2010?)

How I²C EEPROM Talks To The Bus

September 1, 2016 by Jenny List 9 Comments

You will probably be familiar with I²C, a serial bus typically used for not-very-fast communication with microcontroller peripherals. It’s likely though that unless you are an I²C wizard you won’t be intimately familiar with the intricacies of its operation, and each new device will bring a lengthy spell of studying data sheets and head-scratching.

If the previous paragraph describes you, read on. [Clint Stevenson] wrote a library for interfacing I²C EEPROMs to Arduino platforms, and when a user found a bug when using it on an ATtiny85, he wrote up his solution. The resulting piece is a clear explanation of how I²C EEPROMs talk to the bus, the various operations you can perform on them, and the overhead each places on the bus. He then goes on to explain EEPROM timing, and how since it takes the device a while to perform each task, the microcontroller must be sure it has completed before moving to the next one.

In the case of [Clint]’s library, the problem turned out to be a minor incompatibility with the Arduino Wire library over handling I²C start conditions. I²C has a clock and a data line, both of which are high when no tasks are being performed. A start condition indicates to the devices on the bus that something is about to happen, and is indicated by the data line going low while the clock line stays high for a while before the clock line starts up and the data line carries the I²C command. He’s posted samples of code on the page linked above, and you can find his library in his GitHub repository.

If you want to know more about I²C, take a look at Hackaday Editor [Elliot Williams’] masterclasses on the subject: What could go wrong, I²C edition, and Embed With Elliot, I²C bus scanning.

Serial EEPROM die picture, By Epop (Own work) [CC0], via Wikimedia Commons.

When You Need A Scope, You Need A Scope

August 4, 2016 by Elliot Williams 22 Comments

Sometimes there’s just no substitute for the right diagnostic tool. [Ankit] was trying to port some I2C code from an Arduino platform to an ARM chip. When the latter code wasn’t working, he got clever and wrote a small sketch for the Arduino which would echo each byte that came across I2C out to the serial line. The bytes all looked right, yet the OLED still wasn’t working.

Time to bring out the right tool for the job: a logic analyzer or oscilloscope. Once he did that, the problem was obvious (see banner image — Arduino on top, ARM on bottom): he misunderstood what the ARM code was doing and was accidentally sending an I2C stop/start signal between two bytes. With that figured, he was on the right track in no time.

We just ran an epic post on troubleshooting I2C, and we’ll absolutely attest to the utility of having a scope or logic analyzer on hand when debugging communications. If you suspect that the bits aren’t going where they’re supposed to, there’s one way to find out. It’s conceivable that [Ankit] could have dug his way through the AVR’s hardware I2C peripheral documentation and managed to find the status codes that would have also given him the same insight, but it’s often the case that putting a scope on it is the quick and easy way out.

What Could Go Wrong? I2C Edition

July 19, 2016 by Elliot Williams 53 Comments

I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master needs to wait. It sounds perfect.

In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.

But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.

Continue reading “What Could Go Wrong? I2C Edition” →

I2C Bit Injection Adds Memory Banks To Everything

July 12, 2016 by Moritz Walter 18 Comments

[Igor] wished to upgrade his newly acquired radio — a Baofeng UV-82 — with a larger memory for storing additional scanning channels, and came up with a very elegant solution: Replacing it’s EEPROM with a larger one and injecting the additional memory address bits into the I2C data line.

Continue reading “I2C Bit Injection Adds Memory Banks To Everything” →