I’ve participated in Maker Faire every year since its inception — first as a helper for the Electric Giraffe crew, then later reporting for the Hack a Day blog. Exhibiting as a maker was long overdue, and I’m finally there on the 2012 roster. You’ll find me in Fiesta Hall…the Big Dark Room…with a collection of projects simply called “Stuff I’ve Done.”

The title is a bit of a misnomer. Most of what I selected to bring are either collaborations or showcasing others’ work…but the name was already in print by then. Ah well.

What’s On Display

Adalight: this adds ambient wall lighting effects to video content from a PC, creating a more immersive experience…think of it as a subwoofer for your eyes. Adalight was my first collaboration with Adafruit Industries, and still the most popular…I think because it ties the otherwise abstract Arduino platform into something “real” that people enjoy doing anyway: watching movies.
Spectro: it’s a music visualizer! It’s a clock! It’s programmable…make it whatever you want! My latest collaboration with Adafruit is being unveiled at Maker Faire. I designed most of the software and the laser-cut enclosure, while Limor Fried designed the custom Arduino shield that makes this a solder-free kit!
Bill Bell’s Foureyes LightStick: not my work, but this holds a special place and I wanted to showcase it. Artist Bill Bell invented the LightStick “saccadic persistence of vision” illusion in the 1980s, and one of his early displays famously hung in San Francisco’s Exploratorium museum. The idea influenced my early impression of technology: that it’s not all bits and bytes, that an engaging user experience may draw from disparate fields as biology, psychology, art and theatre. 25 years later, I found one of Bell’s LightStick prototypes in a thrift store just a few blocks from my home. I’m displaying it at Maker Faire in the hope that it might likewise inspire the next generation.
Creatures Persistence of Vision Display: a piece inspired by Bill Bell’s LightSticks. The original Exploratorium illusion later gave way to a sophisticated display leading the viewer’s gaze across multiple concurrent LightSticks. This miniature model follows the same principle using an Arduino microcontroller and other easily-sourced components. (Pixel art creatures were created by the talented Neogeen.)
LED Arrays: these LED “pixels” were originally developed for outdoor signs, but their simplicity and low cost makes them suited to other creative endeavors. They’re like the ultimate Christmas lights…link up as many or as few as needed, each one individually addressable in software. What will you create?

Where to Find Stuff

I’m not selling kits at Maker Faire, just demonstrating the ideas. I encourage anyone intrigued by electronics and computers — geek and artist alike — to pick up a soldering iron and start playing with these things. Experiment and allow yourself to make mistakes, it’s all part of learning. Here’s where to find some of the items on display:

• Adafruit Industries: not just because I’m working with them…their tech support really is first-rate! Aside from the kits, Adafruit is an excellent source for additional LED pixels and related bits and bobs: microcontrollers, power supplies, breadboards and tools. They’re major proponents of open source hardware and software, with their designs and code all freely available online. The basic Adalight kit is also offered via the Maker Shed online.
• Cool Neon Lighting: their Total Control Lighting system is another good choice for LED pixels. The ready-made controllers may be a better fit if you’re seeking a plug-and-play solution vs. full software control using your own code. An interesting variety of accessories and other blinkenlights make this bay area business a perennial favorite for the Burning Man crowd.
• SparkFun Electronics: more LEDs and interesting parts and sensors. Another champion of open source with schematics and CAD files available for many of their products, their blog is always an interesting read with some pretty good tutorials.
• Arduino is currently the most popular hobbyist microcontroller, and is used in most of my Maker Faire demos. The software is free to download, cross-platform, and the site includes tutorials and a support forum. This ShiftOut Tutorial explains the basic principles used by the Creatures LED persistence of vision demo. Arduino boards are available from many sources, even Radio Shack now.
• Processing is a programming environment with an emphasis on multimedia — graphics, sound and interactivity — and is geared toward first-time programmers. This also is free and cross-platform, and is used in several of the Maker Faire exhibits.

Frequently Asked Questions

Q: Will the Adalight software work with my computer?
A: Most likely, yes. Most of the code uses the cross-platform Processing environment, which runs equally well on Windows, Mac (Intel only) and Linux PCs.

Q: When will Spectro be available, and how much will it cost?
A: Watch for it this summer on Adafruit.com. The price is still being worked out as we decide what to include with the kit, but expect it to be more than $100 and less than $200.

Q: Will Spectro work with an Arduino Mega?
A: No…the shield is pretty tightly coupled to the Arduino Uno design.

(Additional Q&A will be posted following Maker Faire, once we know which Questions are actually Frequently Asked!)

Total Control Lighting is a system of individually-addressible full-color LED “pixels” that can be shaped into any display imaginable. It’s a new offering from Funhouse Productions, who’ve been marketing their Cool Neon electroluminescent wire to creative types for years now, practically defining the after-dark aesthetic of the Burning Man arts festival.

The appeal of the Total Control Lighting system is that it scales linearly…just chain one strand of LEDs after the next, like Christmas lights. One end plugs into a controller box, which can issue preprogrammed color sequences, or others can load animation data from an SD card. In more sophisticated setups, the controller in turn connects to a computer, which can then command every LED individually and in real time. That’s where this project comes in…

These controller boxes offer some fine features, and come as a tidy, pre-packaged solution. They can run unattended, without any computer attached, streaming data from an SD card. Or they can be situated remotely on a network, far away from the computer actually generating the display. They also cost money, which I’d rather pour into buying more LEDs! Fortunately, for the technically-minded, we can cobble together our own home-built alternative for about fifteen bucks.

Some folks are already using an Arduino as a PC-to-LED bridge, and that works great up to a point. But when you start getting into larger displays and faster frame rates (such as video and persistence-of-vision displays), it’s like trying to funnel the traffic from an eight lane highway down a narrow gravel path. This alternate controller uses an FTDI USB-to-serial adapter, along with a C library to run it using “bitbang mode,” which is explained in this article at Hack a Day. The bitbang FTDI route can provide significantly higher throughput.

That’s the good news. The bad news, perhaps, is that this is just a low-level C library. You’ll still need to write the code to make it actually do anything. If the existing controllers already handle everything you need, be it pleasing color patterns or playing back animation sequences from an SD card, that extra investment might save you a lot of headache. But if hacking a Kinect controller for an interactive POV display is more your style, or anything else weird and unexpected, this might be just the thing you need. The code is open-source, and works on Mac, Linux and Windows.

Some outwardly identical-looking LED pixels are offered from other sources such as Bliptronics and Adafruit. Without getting into the all the geeky details, while these other types work fantastically well with a microcontroller, they just can’t be driven by the FTDI adapter without unsightly flicker. What distinguishes the Total Control Lighting pixels is the use of a newer LED driver chip — the P9813 — that’s essentially immune to the small timing issues of the FTDI approach. The code unfortunately will not work with those other pixels.

The library is available for download from this GitHub repository. Until I can get around to providing better documentation here, the README file included with the code explains its use and depicts the hardware setup with awful ASCII art. Any significant progress will also be posted on this YouTube channel.

The selections were culled from about 80 total hours of footage, a collection I’ve been meaning to digitize for years now. Even the plan itself is vintage: 100MHz PowerPC Macs and the VideoCD format were cutting edge when the scheme was first hatched, but the process proved so tedious on then-current hardware that the idea was shelved until the source tapes resurfaced during a recent cleaning. Fortunately all but a couple still played. So glad I waited! Not only is the process now painless, but resources like YouTube—with bandwidth and capacity beyond anything we could imagine at the time—make it possible to share these clips with the world.

Rather than blindly upload the kitchen sink, I’ve tried to select particularly historical, unusual or prescient work, and wherever possible have included a bit of background or even some interesting trivia in the video descriptions; quality over quantity.

Visit the VintageCG channel on YouTube.

My first substantive tutorial for the site describes the use of FTDI Bitbang Mode, a method of using a common, inexpensive USB-to-serial adapter as a quick & dirty GPIO interface. This facilitates the sort of prototyping typically done using microcontrollers, but in the comfortable and unconstrained development environment of mainstream PCs. The technique is particularly well-suited to SPI-type protocols; I’ve had this communicating with shift registers, LED driver chips and even video overlay ICs, as well as reading various optical rotary and linear encoders.

You can read the full article over at hackaday.com.

The Explorer 16 Development Board is Microchip’s mainline trainer/project board for 16-bit (and lately now, 32-bit) microcontrollers. The modular design of this board allows use of three different microcontroller families along with add-ons for networking, storage, audio, LCD graphics and more, and providing a common point of reference that allows Microchip to provide working example software templates for these different types of projects.

For all its virtues, this is not to say the experience can’t be improved. What follows are a few simple tidbits I’ve learned for enhancing the functionality of this kit.

A typical Explorer 16 development setup (shown at right) is comprised of several parts:

1. The Explorer 16 board itself, containing a microcontroller PIM (plug-in module) and any optional attached peripherals.
2. A Microchip programmer/debugger such as the PICkit 2, ICD2 or ICD3, or RealICE. (Having something of a Mac inclination, I tend toward the entry-level PICkit 2 as there’s at least portable open-source software available for this programmer. For amateur or student use, this is often perfectly adequate.)
3. An RJ-11 to ICSP adapter cable connects the PICkit 2 to the Explorer 16 programming socket. Other programmers use a cable with an RJ-11 plug at both ends.
4. A 9 to 15 volt DC power supply drives the board and any attached peripherals.

Implied in this setup but not specifically highlighted are the host development system running the MPLAB IDE development environment (or alternate software as detailed in my other articles), and a USB connection between this system and the PICkit 2 or other programmer device.

Collectively this makes for a great deal of clutter on one’s desk, and the assorted parts can be frustrating to travel with. My frugal nature would also have preferred any opportunity to avoid unnecessary expense. Let’s see what can be done to fix this…

Hack #1: Lose the RJ-11 to ICSP Cable, Save $10

This hardly even qualifies as a “hack,” since the feature is built-in and documented. But there’s a right way and a wrong way to go about it…

Situated adjacent to the PICtail™ Plus slot connector (or between the two, if you’ve soldered on a second), position J14 is a 6-pin ICSP header to which a PICkit 2 can connect directly. Earlier Explorer 16 boards have plated vias where a 6-pin row connector can optionally be added, but more recent supplies of the board already have this connector soldered in place — there’s nothing to add.

There’s just one small problem: the silkscreen on the face of the board is incorrect — the ICSP header is turned around, and where they’ve marked pin 1 is actually pin 6! First-time users will often try this connector as labeled, then give up in disgust after it doesn’t work and go back to using the cable. Perhaps the silkscreen will be fixed on future boards by the time you’re reading this; in either case, use the photo at right as an indication of how the PICkit 2 is supposed to attach, with the top face and button facing the procesor PIM.

Hack #2: Lose the PICkit 2, Save $35

Appendix B in the Explorer 16 Development Board User’s Guide describes a tremendously useful feature that unfortunately was never implemented: the intent was to allow an auxiliary PIC18 chip on the Explorer 16 board to perform the same functions as the separate PICkit 2, using the board’s USB connector to permit downloading code without a separate programmer device. All the necessary components are still present on the board, but they sit idle as the necessary firmware was never written and the feature was dropped. You can ignore that entire chapter of the manual.

The good news is that one enterprising user, Rafal Waniurski, has taken it upon himself to implement the firmware that enables this missing capability, and has given permission to repost his work here. Once this firmware is installed, any host-side software that works with a regular PICkit 2 will also work with the Explorer 16 board directly via USB; no separate programmer is needed. If you have a colleague or instructor with another device programmer you can borrow, then you can set up your board this way and avoid the expense and additional clutter of a separate PICkit 2.

The process works like this:

1. Download this firmware file:
   PK2_Explorer16_V0210007-BL.hex.
2. Move the jumper at position J7 (not the switch directly above it) to the “F4550” position (two left pins).
3. Connect PICkit 2 to ICSP header (or other Microchip programmer to the RJ-11 jack).
4. Write firmware as appropriate to the device programmer and operating system in use; for a PICkit 2 and Windows, run the PICkit 2 application, select “Import Hex” from the File menu and choose the previously-downloaded firmware file, then click the “Write” button. For Mac or Linux using the command-line pk2cmd program, type:

   pk2cmd -PPIC18F4550 -M -F ./PK2_Explorer16_V0210007-BL.hex -R

   Note: if the above method ‘hangs’ after writing the firmware, try using Microchip’s Windows-based PICkit 2 program (via Boot Camp or virtualization) to download the hex file to the Explorer 16.

5. Move jumper J7 back to the “PIC24” position.
6. Party!

Once configured as above, there are still a couple of differences from a normal PICkit 2:

1. The Explorer 16 uses a USB “B” connector, versus a “Mini-B” on the PICkit 2, so be sure to pack the right cable.
2. The board must be powered from an external DC supply before it will show up on the USB bus (unlike the PICkit 2, which is entirely bus-powered). But see Hack #3 for more on this…
3. Contrary to what’s printed in the aforementioned manual, never attempt to update the board with any regular PICkit 2 firmware! Use only this custom firmware and follow this same procedure if applying updates. I will keep tabs on the state of the firmware development and provide the current version here.

Hack #3: Lose the Power Supply, Save $24

This tip also arrived by way of Rafal Waniurski, who developed the PICkit 2-masquerading firmware:

The Explorer 16 has a barrel-jack connector for an external 9 to 15 volt DC power supply. Rummaging through my collection of “wall warts” I was fortunate enough to find one of the right voltage, polarity and plug diameter (from a Maxtor external hard drive), but if you’re unable to turn up something suitable then purchasing the correct one directly from Microchip will set you back a ludicrous $24.00.

With a simple modification it’s possible to power the Explorer 16 board from a USB port. This requires soldering one or two Schottky diodes of type 1N5817 or 1N5819 between specific points on the back of the board. Schottky diodes are required as they have a very low voltage drop; combined with the 5 volts from the USB port, it’s just enough overhead to allow the 3.3 volt regulator on the board to operate.

The diagram at right shows the placement and polarity of the two diodes. Looking at the back side of the board, with the barrel jack under the bottom-right corner, the anode side of both diodes should connect to the 5 volt supply from the USB connector — this is the lower-left of the four pin cluster near the center right edge of the board. The cathode end (with a silver mark) of one diode connects to the cathode end of the existing diode at the corner of the board, adjacent to the power jack, while the other connects to the nearby +5 volt test point. Both diodes pass by a number of exposed contacts on the back of the board, so it’s absolutely essential to cover the bare leads of the diodes with heat-shrink tubing or a length of insulation stripped from 24 gauge wire. After soldering, I also like to use a few dots of hot-melt glue to help secure things in case the board gets knocked around.

Drawing from the USB port means that available current is limited to about 200 milliamps — enough for a modestly-populated board, but not higher-current accessories such as the Graphics PICtail board — and it’s necessary to use a powered USB hub or connect directly to a port on the computer. The “9V” points on the breadboard section will only provide about 4.8 volts in this configuration. If any of these are inadequate for a specific situation, it’s still possible to connect an external DC power source when needed.

With all of the modifications complete, basic Explorer 16 development requires only the board and a single USB cable (as seen at the top of the page), leaving the rest of one’s desk space free for reference books, test equipment, lunch or a collection of small plastic dinosaurs.

This article is not a comprehensive survey of every Microchip PIC development option for Mac and Linux, just a summary of the particular hardware and a few software choices I’ve found that most reliably meet my own criteria.

Important Update:

This article is now enormously obsolete…and I couldn’t be happier! Microchip has begun supporting cross-platform development in earnest. Their MPLAB X development environment runs equally well on Windows, Mac and Linux and supports the full range of PIC chips and programmers/debuggers. Though still in a beta state, this tool is working quite well and continues to improve with every release. I’ll be deleting this article in the future; just keeping it around in the interim should the information still be of use to anyone.

The Issues:

• Many inexpensive or homebrew PIC programmers have been based on legacy I/O ports (serial or parallel), but all modern Macintosh systems (and increasingly PCs, especially netbooks and small form-factor systems) are “legacy free,” eschewing these older ports in favor of USB.
• Adapters for USB to serial or parallel are available but introduce their own issues, as does emulation or virtualization software.
• Low-cost USB PIC programmers are on the rise, but support for non-Windows systems has been spotty.
• Many existing PIC-on-Mac (or Linux) sites contain obsolete information or dead links.

The Desired Outcome:

An affordable hardware and software toolchain closest to the native physical interfaces and operating system, minimizing or eliminating the use of adapters, emulators and other stopgap measures that add cost, bulk, complexity and compromise the stability of the development process.

Hardware

There are many devices and methods of getting code onto a PIC. Later articles might detail some of these options, but at present, for the hobbyist or casual developer, Microchip’s PICkit 2 — their entry-level programmer — seems the most generically useful choice:

This is available in a variety of bundles:

• PICkit 2 (Microchip part number PG164120, $35) – this is the standalone programmer with no additional parts; bring your own PIC microcontroller.
• PICkit 2 Starter Kit (part number DV164120, $50) – this bundles the PICkit 2 programmer with Microchip’s Low Pin Count Demo Board containing a socketed 20-pin PIC16F690, four LEDs and one switch and potentiometer. Other 8-, 14- and 20-pin PICs can be used in this socket.
• PICkit 2 Debug Express (DV164121, $50) – bundles a 44-pin Demo Board containing a nonremovable PIC16F887, eight LEDs and the same switch and potentiometer as above. Don’t be misled by the “Debug Express” name of this particular kit. All versions of the PICkit 2 are equally capable of debugging with most PIC microcontrollers (though currently only when used with Windows systems).
• PIC18F4xK20 Starter Kit (DV164124, $100) – this bundle includes an elaborate demo board containing a more capable PIC18 microcontroller, a small OLED display, analog audio in and out jacks, a serial EEPROM, daughterboard connector and other doodads. Wow!

A demo board is not a requirement — any PICkit 2 can program PIC microcontrollers on a breadboard or in-circuit — but the starter kits are reasonably priced and the included projects are a good way for beginners to learn the ropes.

A number of “compatible” third-party programmers have since come to market, some undercutting Microchip’s product by a few dollars…but I’ve read reports of unreliable behavior from some of the cheap imported models. Given the modest cost of the official starter kits, it makes sense to simply buy directly from the source or their distributors (DigiKey, Mouser, Newark, etc.).

Microchip has since released a PICkit 3, but this is not backwardly-compatible with the PICkit 2 and will not work on non-Windows systems. The PICkit 2 is currently the only official programmer with solid open source support.

Software

If using a Windows-based system, this is a trivial matter: install the development software included with the PICkit 2 and get started. For alternative operating systems, things are not so cut-and-dried, and one must choose an approach most suited to their own development and usage patterns:

Option 1: Virtualization or Dual-Booting

MPLAB IDE — Microchip’s Windows-based development environment — works reasonably well under virtualization software such as VMware Workstation or Fusion, Parallels Desktop or the fantastic open-source VirtualBox…or alternately by “dual booting” a system for native Windows operation. Of course this is only an option for x86-based systems (not PowerPC), and is not without its share of issues.

If you choose the virtualization route, something to watch out for is that downloading code to chips using the PICkit 2 directly from within MPLAB IDE is horribly unreliable. The solution is to run both MPLAB IDE and Microchip’s small PICkit 2 utility concurrently, using the former program to compile the code and the latter to burn it to the chip (an “Auto Import” mode in the latter makes this easy).

So virtualization does let us develop PIC code on Mac or Linux systems, but it falls short of an optimal “shortest path” solution.

Option 2: HI-TECH C Compiler

Third-party commercial compilers produced by HI-TECH Software have been available for a number of years now. While they claimed Mac and Linux support, for the longest time this was rather dodgy — broken links, crashing software, a confusing product lineup among other things. HI-TECH has since been acquired by Microchip, and the outlook for this software has improved considerably.

The compilers are available for Windows, Linux and Mac OS X and offer different licensing options:

• The “Lite” mode is free (even for commercial use) but optimization options are seriously curtailed. Still, it’s perfectly adequate for training and student use and is not impaired in any other way (code size, etc.).
• A “Pro” evaluation install is fully functional — optimization and all — for a period of 45 days.
• The full-on “Pro” license — which, at $1195, is clearly intended for actual professional developers — remains fully functional and includes a year of priority technical support.

The HI-TECH compilers include their own IDE which is based on Eclipse. Personally I’m not especially fond of IDEs, and Eclipse is among the most elephantine of the genre…but if you’re familiar with this environment from prior development work, well hey, you’re all set. If text-based development is more your style, the HI-TECH compilers can also be invoked from the command line.

Option 3: Open Source Tools

Community-developed tools for PIC development likewise started out quite rough but have since crossed a threshold of viability. A complete development toolchain consists of three parts:

• GPUTILS (GNU PIC Utilities) includes an assembler (gpsasm) that aims to be fully source compatible with Microchip’s own tools, and my own experiences have borne this out; code taken directly from MPLAB projects works with gpasm without modification. The project page does mention a handful of esoteric incompatibilities and bugs but I have never encountered these in regular use.
• SDCC (Small Device C Compiler) supports a variety of microcontroller platforms; 8-bit PIC support is a recent addition and still a work in progress. I’ve tested simple student-level programs against it with no trouble at all, but at present there’s the risk it may be unsuited to more complex tasks.
• PK2CMD is Microchip’s open-source tool for downloading code to a microcontroller using the PICkit 2.

These tools are all command line operated at present; there is no GUI or IDE. Savvy users might be able to integrate them with a development environment such as Eclipse; I’ve not figured this out because I’m an old fart and like developing on the command line. Uphill. In the snow.

Installing GPUTILS

This takes just a few minutes to complete, and the resulting executable will be installed in /usr/local/bin. Make sure this directory is added to your PATH environment variable.

Installing SDCC

Couldn’t be simpler — pre-built installers for all the major operating systems are available on the project’s download page. It’s also available in package format for Linux users; use Synaptic or apt-get to install the package sdcc. If for some reason you need to build this from the source code, the procedure to compile and install this uses the exact sequence of commands previously shown for GPUTILS.

Installing PK2CMD

This is also available as a precompiled installer for various operating systems, or can be built from source. The links for these are buried amidst the PICkit 2 product page (the “Download” box second from the bottom).

If compiling from source, the build process for PK2CMD is slightly different than the other tools. After extracting the source archive, the ./configure step isn’t necessary. Instead, just type the appropriate make command for your operating system:

Next type:

sudo make install

…and then make sure both /usr/local/bin and /usr/share/pk2 are in your PATH environment variable. e.g. in ~/.profile, add this line:

export PATH=$PATH:/usr/local/bin:/usr/share/pk2

Using the Open Source Tools

One aspect of SDCC initially had me confused: the documentation refers to the “pic14” and “pic16” ports of the compiler, but it turns out these do not correspond to Microchip’s part naming conventions. Rather, each refers to the instruction word size (in bits) on the midrange and high performance microcontrollers; in other words, you compile for the PIC16 using the pic14 option, and PIC18 using the pic16 option. Once that was cleared up, everything proceeded smoothly.

In addition to the documentation included with each, all three tools offer command-line help:

sdcc –help
gpasm –help
pk2cmd -?

In order to avoid a lot of repetitive typing (and having to remember all of the fiddly options for pk2cmd), I’ll usually group all of the files related to a single project into one folder and then create a Makefile that includes common operations such as “make write” or “make on”, like this:

# Example makefile for open source PIC toolchain
# Specific microcontroller type:
DEVICE=pic18f2620
# C compiler, assembler, device programmer:
CC=sdcc -mpic16
AS=gpasm -p$(DEVICE)
PK2=pk2cmd -P$(DEVICE)

All: foo.hex

foo.hex: foo.c foo.h
    $(CC) foo.c

write:
    $(PK2) -M -Ffoo.hex

on:
    $(PK2) -T

off:
    $(PK2) -W

erase:
    $(PK2) -E

clean:
    rm -f *.o *.cod *.hex *.lst *.err

I²C (Inter-Integrated Circuit) is a two-wire serial bus typically used inside computers for low-level communication between components, but it’s also seen in robotics and hobbyist electronics for interfacing all manner of sensors, displays and actuators. I²C connections are often readily available on microcontrollers and esoteric embedded systems, but there’s traditionally little call for end-user access to this bus on mainstream personal computers. Lately though, netbooks and other small form-factor systems are increasingly being put to use as the high-powered “brains” of many homebrew projects. To sense and react in the physical world, a USB to I²C adapter (or “bridge”) device is typically used, often at considerable expense.

DDC, supported by most graphics cards and monitors produced since the late 1990s, is a communication channel within a video cable that allows the computer and monitor to negotiate mutually compatible resolutions and permit software control of functions normally accessed with physical buttons on the display.

DDC is, in fact, simply an implementation of an I²C bus with a few established rules. By tapping into this connection between the computer and monitor (or better yet, making use of the DDC lines on an spare unused video port, such as the external monitor connection on a laptop), one can interface with many I²C devices at virtually no expense, bypassing the usual need for an adapter device entirely.

Commercial USB to I²C adapters can cost $100, $250, sometimes even more, and driver support is spotty for systems outside the popular Windows fold. Using an Arduino or other USB-capable microcontroller as an intermediary is one affordable alternative. But the method outlined here requires nothing more than a modified video cable…I just bought one at a garage sale for 50 cents, and that’s enough to make two such adapters!

Being a quick and dirty hack, there are some limitations to this approach:

1. Most significantly, it does not work in Windows at present. I’ve pursued a number of avenues but have yet to produce a working equivalent for that operating system. Please see the notes at the end of this article regarding the current state of Windows affairs.
2. Even among Macintosh and Linux systems, the compatible range of hardware is limited. The graphics card driver will determine whether application code is allowed access to the DDC lines at all.
   • On the Mac, systems with Intel integrated graphics or ATI chipsets appear to support this scheme, while those with NVIDIA graphics are out of luck. As nearly the entire current Mac lineup has now transitioned to NVIDIA graphics, the usefulness of this hack is relegated mostly to earlier Mac models and just a handful of current iMac and Mac Pro configurations.
   • I’ve had few opportunities to test with Linux systems thus far, but ATI and NVIDIA graphics seem to show solid support while Intel integrated (e.g. GMA 910) was a no-go.

   Compatibility Matrix

3. Not all I²C devices are compatible with this approach, and the selection varies somewhat by operating system. There seems to be some variation in the allowable range of serial timings sent or received by both the host and I²C device, and in some combinations these ranges just don’t overlap. For example, a Nintendo Wii Nunchuk controller will work with Linux but not Mac OS X.
4. This is limited to being a “single-master” I²C bus; one can poll devices for their state, but there’s no means for the computer to respond to events that originate elsewhere on the bus. And available power is limited to 5 volts at a scant 50 milliamps.
5. There’s always the possibility of damage by incorrect wiring or misplaced voltages. Attempting this hack at all is likely a warranty-voiding operation and I assume no liability for damage inflicted, so tread forth carefully and always mount a scratch monkey!

There are still plenty of fun projects that can be attempted, so with those caveats out of the way, let’s proceed! All that’s required is a modified video cable, or, if tapping an unused video port, simply the appropriate end connector (but it’s often cheaper to simply buy the full cable and cut it in half). If the port will still be used for a monitor connection, it’s necessary to create a “Y” or “hydra” cable that allows one’s I²C device(s) and the monitor to be attached at the same time (sharing the DDC lines).

Single-Ended Cable	“Y” Cable
Connects to an unused video port.	Shares video port among monitor and I2C device(s).

When modifying an existing cable, after removing just the outer shielding, the DDC wires are usually visible at this point, while the lines carrying video signals are wrapped inside further-shielded bundles. A multimeter or continuity tester will help correlate wires to pins. DDC establishes four wires: +5VDC, ground, serial data and serial clock, the pin numbers of which will vary depending on the type of video port used. Refer to pinouts.ru, Wikipedia or other sources if you need more help than the diagrams below can provide.

The pins of interest are as follows:

VGA:		DVI:		HDMI (Type A):
Pin	Description	Pin	Description	Pin	Description
5	Ground	6	Clock	15	Clock
9*	+5VDC	7	Data	16	Data
12	Data	14	+5VDC	17	Ground
15	Clock	15	Ground	18	+5VDC

* Note that on some VGA cables (perhaps even a majority), pin 9 is not present (occasionally others as well). Just examime the male end connector to see if it’s even worth dissecting — the missing pins are quite apparent. You’ll want to use a cable with the full complement of pins, or work from just a bare D-sub 15 connector (if scrounging at the local swap meet for cheap cables is not your style, these connectors can be found at Radio Shack for $1.99).

The DDC clock and data lines correspond directly to I²C clock and data. Pull-up resistors are not required — that’s already implemented in the graphics card — so it’s just the cable, your I²C device(s) and a bit of wire.

Connect the corresponding I²C lines to your device as required, and the other end of the cable to the desired video port. If using a “Y” splitter cable with a monitor connected, one’s power budget should be trimmed by a few extra milliamps to ensure enough power for the DDC chip within the display. There should be enough current to drive a microcontroller and an LED or possibly two…but if the I²C device(s) to be connected are going to use any substantial amount of current, it may be wise to power the circuit externally and use a I²C buffer or, if the device operates at a different voltage, a logic level converter (such as SparkFun part BOB-08745). Also, if using with a display connected, two I²C addresses are reserved for the monitor and should not be used: 0×37 and 0×50.

While the gritty details of the I²C protocol are taken care of by the i2c.o library (provided below) and the OS-specific libraries on which it in turn depends, the specific message sequence required by any given device must be implemented within one’s own code and will vary from one device to the next; the library does not automatically handle all this. Manufacturers’ datasheets will document the I²C messages needed, and the amount of code required is not onerous. Several short example programs are included: reading a Nintendo Wii Nunchuk controller accessory (currently Linux only), reading a Microchip TCN75A temperature sensor, writing to a Microchip 256 Kbit serial EEPROM, flashing a BlinkM “smart LED,” and another that interfaces with a Mindsensors I2C-SC8 8 channel servo controller.

Bringing it All Together
Here’s a quick test case involving multiple I2C devices: the computer (out of frame, to the right) reads the current temperature from a sensor, then updates a hobby servo being used as a makeshift dial indicator. The readings are also logged to EEPROM for posterity. The example code can do all of these functions, plus others.

Click to Download C Source Code (tar.gz)

Installation

No special procedure is required for Mac systems, aside from having GCC installed in order to compile the code. GCC is one component of Xcode, an optional installer on your original Mac OS X DVD-ROM, or can be downloaded from Apple’s developer web site. Rather than get into the whole graphical IDE, I’m simply invoking the compiler from a Terminal window. If you have a supported video card and one of the compatible I²C devices attached, simply compile (“make all”) and run (e.g. “./temperature”). You can skip the rest of these directions and go right to the “Using the Library” section.

While the source code for Linux is simpler, the setup procedure unfortunately is not. You’ll need root access. Frequently. This is how I install it under Ubuntu 7.04 and later:

1. Install the lm-sensors package:
   

   sudo apt-get install lm-sensors

2. Enable kernel modules for I²C and the specific video driver:
   

   sudo modprobe i2c-dev

   sudo modprobe radeonfb

   The above is for an ATI Radeon. You might need a different module specific to your system. Use the command “sudo modprobe -l” (that’s a lowercase L, not a one) for a full list of kernel modules, and try to locate one that matches your graphics chip vendor.)

   Alternately, to load the I²C modules automatically at boot-time, edit the file /etc/modules and add these lines:

   i2c-dev
   radeonfb

   Again, assuming Radeon graphics here; put your actual module name there.

   Once the kernel modules are loaded, the files /dev/i2c-* will then correspond to each I²C bus on the system. Not all of these relate to video out though; some may correspond to internal I²C buses in the computer (e.g. system health, RAM controller, etc.). The i2cdetect program (installed as part of lm-sensors) will list and briefly describe each I²C interface present. Look for the one that matches the desired video port. On the ThinkPad I used for development, /dev/i2c-2 corresponds to the VGA port. If the output of i2cdetect does not mention any video ports (VGA, DVI, or HDMI), then it’s probable that the driver does not support I²C and this hack will not work, or a different video card module may simply need to be loaded.

3. Edit the Makefile, commenting out the Mac-specific lines and enabling the Linux-related flags. Then “make all” to build the library and example programs.
4. Access to the /dev/i2c-* devices is normally available only to the root user, so there are a few options for invoking the example programs. The most sensible and controlled is to run each with the sudo command, e.g. “sudo ./nunchuk”. If you’re on a personal system and can afford to be less pedantic about security, other options include logging in and running the programs as root, chown/chmod-ing the executables to root and enabling the setuid bit, or chmod-ing the /dev/i2c-* files to enable read/write access for all users (which would need to be reapplied after each reboot).

Using the Library

The C API is super-basic, with just three functions:

I2Copen()

Opens the I²C (DDC) bus for subsequent communication. As some systems may support multiple “heads” and thus have multiple DDC interfaces, the code in i2c-osx.c or i2c-linux.c may to be adapted to your specific situation. On Macs the code is currently rigged to use the last connection found; on a single-head system (e.g. Mac mini), this would be the single video out port, while on a potentially two-headed system (e.g. MacBook, late-model iMac) this would be the video out port, regardless of whether there’s a monitor attached. Multi-headed systems (e.g. Mac Pro) may require some tweaks to the code to access a specific graphics card and port. For Linux, the code is rigged to open /dev/i2c-2, which corresponds to the VGA connector on my ThinkPad system used during development, but you’ll probably want to change this for your particular situation. Review the notes above regarding Linux installation.

I2Cmsg(short address, unsigned char *sendBuf, int sendBytes, unsigned char *replyBuf, int replyBytes)

Issues an I²C request and/or reads response over the previously-opened I²C bus. The address of the device is often factory-defined, and the size and content of the request data are entirely device-dependent (see the example code for several practical cases). You’ll need to work with the datasheet provided for your specific device.

An important point should be made here regarding the first parameter: there is some disagreement as to just what constitutes a valid I²C address. The I²C protocol defines data packets in 8-bit chunks, with the first byte of an I²C message containing a 7-bit device identifier and one bit indicating whether this is a read or write operation. Most presume the 7-bit value to define the address, but in some implementations they’ll include the read/write bit in referring the address, or — because the R/W flag is the least signficant bit — document the device as having two sequential addresses (one each for reading and writing). Linux and OSX disagree here; this API follows the 7-bit convention and adjusts the value passed as needed for the host operating system. If a device does not seem to be responding at the address given in the datasheet, try dividing the number by two, which shifts off the R/W bit to produce a 7-bit address.

This example from a Microchip datasheet shows an 8-bit I2C address byte that includes a ‘write’ bit. But other documents (and this API) follow the convention of calling addresses by the 7-bit component only.

I2Cclose()

Closes the previously-opened I²C bus.

Return values, defined in i2c.h, are currently very limited. All of the functions will return a value of zero (or I2C_ERR_NONE) on successful completion. The I2Copen() function may return I2C_ERR_OPEN if no available DDC bus can be found (or, on Linux, if not running as root). On the Mac, I2Cmsg() may return various error values defined in /System/Library/Frameworks/IOKit.framework/Headers/IOReturn.h (e.g. 0x2c0 or kIOReturnNoDevice).

The library is not especially comprehensive; there are quite a few limitations and assumptions made at present (for example, only one I²C bus can be open at a time). Consider this just a starting point for your own code. The core meat-and-potatoes of opening and communicating over the bus can be distilled to just a couple dozen essential lines of code, the rest being error handling, packaging and comments.

Microsoft Windows Status

As explained earlier in this article, I currently do not have a working implementation of this library available for any version of Windows yet. Honest, this is not just asinine OS bashing! Admittedly the platform is one of the less familiar among my development skills, but I have made several honest attempts, still to no avail. If Windows is your native tongue and you’d like to give it a try, I can offer some possible leads:

• In my earliest attempts, web searches for information suggested that the Windows API calls for handling DDC (and thus I²C) were undocumented and proprietary. More recently, reader S. Manabe brought this article at Windows Hardware Developer Central to my attention. The talk of WDM Streams and minidrivers quickly goes over my head, but perhaps Windows-savvy developers could make use of it.
• For users with NVIDIA graphics cards, N. Ekstrom alerted me of the existence of the NVIDIA API and corresponding documentation. I’ve only had time to briefly dabble with this and have produced no working results yet. The documentation also mentions a Mac version of the API, but it seems no library for that platform is available for download.
• Nicomsoft’s WinI2C-DDC appears to have comprehensively solved this problem across all manner of PC hardware, and continues to be actively developed. Unfortunately it costs $495 for a developer license (the $249 Lite version doesn’t support low-level I²C access). A 30-day time-limited evaluation can be downloaded from their web site free of charge. But in the long run, casual tinkerers might prefer a less expensive USB (or even parallel port, if you still have one) hardware solution (or getting the hang of Linux).
• On the hardware front: Aside from the obvious Arduino option, FTDI’s FT2232H and FT4232H multipurpose USB to Multi-Protocol Synchronous Serial Engine chips may provide an inexpensive hardware connection. Evaluation modules from FTDI and DLP Design can be acquired from the likes of Digi-Key or Mouser for under $30. I’ve not yet experimented with the I²C functionality specifically, but the datasheet looks promising and I’ve had tremendous success with other features of FTDI’s chips — watch for a follow-up article at some point.

Acknowledgments

Much thanks to Benny Hsieh for donating development hardware which made the Linux port possible, the authors of ddcci-tool (now ddccontrol) for Linux I²C programming insights, and Tod Kurt of ThingM for entrusting me with one of his BlinkMs for testing at the 2008 Bay Area Maker Faire.