I2C Programming in Go

Thanks for sharing this! I will definitely have a look at your code for inspiration later on, since I'd like to use Go to read 1-wire components (like the DS18B20 temp sensor) through a LinkUSB device, without relying on OWFS.

[1] https://www.adafruit.com/products/381

[2] http://www.ibuttonlink.com/products/linkusb

[3] http://www.owfs.org/

Excellent post! I'll be adding a RasPi to my collection soon, and I've been wrestling with an I2C 20x4 LCD. I'll definitely be rereading your blog when it arrives.

Speaking of the LCD, do you have any suggestions for finding the address of an I2C device? Is there a way to query or scan it to see at which address it responds? I just got the Sainsmart LCD2004 as a gift. Google searches about the device result in forum posts, where people have got it to work with addresses from 0x20 to 0x27 to 0x40 -- one guy had to work it out with a multimeter. Do you know of a more elegant solution than brute-forcing it?

I'm okay with exposing channels as part of an API. The problem was that in my experience doing async reads (especially where the data size is variable, not fixed) where you may have multiple possible callers reading from what is basically the same resource doesn't mesh too well with channels.

Say you have 3 goroutines, any of which might be requesting data from any/all of 3 connected I2C devices all on the same I2C bus. They could signal a read over a channel and then have a return channel they look for the result on, but if there is a single channel per I2C bus, how do they know the result they see is the one they asked for? (As opposed to one being asked for by another goroutine also reading from that channel). You can do it with some sort of token/id system but it gets complicated because if you read the data off the read channel and it isn't yours you have to stuff it back on there for others to read and make sure your goroutine isn't deadlocking everyone else out.

This is, of course, possible to work around while still using channels in many different ways. One way is every time a client calls Read a new channel is created to return the results, but given that the data returned is of variable size and the underlying I2C layer requires you to pass in a pointer to the data buffer being used channels don't buy you much here. Plus you end up with a lot more garbage to collect in the form of new channels being created each time Read is called, which is no big deal on a "big" computer, but when doing Go programming for smaller devices I do try to minimize the amount of garbage that needs to be collected.

When I first got into Go I wanted to do everything with channels and goroutines because where they fit they are awesome, but I've found the "essence" of Go is simplicity, not specific features, and sometimes a plain old mutex is just simpler than a more complex channel system.

And you can, of course, pretty trivially add channels on top of the I2C API like I do in the accel_dump example, where your code knows exactly what the access patterns of any single device will be (whereas the base I2C code doesn't really know or care).

Assuming you have an environment where you can build Go already (which basically means having a working local gcc -- it only needs to be able to produce code for the system you will build the code on, it doesn't have to be a cross-compiler for the target system), it is pretty much as simple as defining those variables I mention in the blog post:

  export GOOS=linux
  export GOARCH=arm
  export GOARM=5

Then build the Go compiler tools using the src/make.bash (.bat on Windows) script that comes with the Go source code. That should build the Go compiler for that platform and stick it within your GOROOT bin directory.

Then prior to building anything you're going to put on the chumby make sure those variables are defined so Go knows which compiler to use.

Dave Cheney's tools make this easy to set up for all the different targets but if you only have one non-local target, it is probably easier to just do it manually by setting the env vars and building the Go compiler again.