As we are adding more devices, it's getting hard to find them. For instance I organized the seedstudio devices under grove which was probably a mistake.

My suggestion is to use the manufacturer name such as seeedstudio, adafruit, pimorini etc..

Thoughts?

@rakyll I believe that if we don't setup travis to update the exp/io packages, we won't get the latest versions and therefore won't notice when upstream changes break our device builds. I might be wrong tho.

The examples are not working. We are not setting the bits per word, SPI mode or the max speed. I don't know what else is missing but was not able to light up my dotstar strip.

README mentions the following:

These libraries rely on Go's new exp/io interfaces and are designed so they can be used as is or via existing Go IoT libraries/frameworks such as GoBot, Embed and hwio.

Even though this is practically possible, this is not the goal of exp/io packages. Trying to achieve it by writing drivers that work against Gobot, Embed, etc also will create confusing and more layers of unnecessary implementation. The more optimal strategy is to rewrite, eg. rewriting Gobot's SPI adaptor layer as an spi.driver and contribute it to golang.org/x/exp/spi.

/cc @mattetti

This is a pretty complete implementation of the Grove LCD device, some of the code could be cleaned up, and the allocation could be reduced. That said I think it's good to merge as is.

Something interesting to notice is that we have to pass 2 devices (one for each address) when this is really a device concern and not a user's.

/cc @rakyll

As per our discussion, I simplified the example I previously wrote that was using signal handling. I did start a new wiki entry explaining how to use signals.

As discussed in the accel3xdigital device PR, it is semantically more correct to use Open vs New and it is also a more symmetrical API since one needs to Close after being done with the device.

"drivers" is a terminology preserved for the protocol drivers. To help with the ambiguity, should we rename the repo to "devices"?

/cc @mattetti

https://github.com/goiot/devices/blob/master/grove/accel3xdigital/examples/monitor/main.go contains an infinite loop and uses signal handling to properly clean things up. While the example is valid to show how to handle a clean shut down, the purpose of the example should be to highlight the usage of the library.

It's therefore better to switch to a for loop that exists after X readings. Cleaning should be done in a defer statement.

Working on a side project to monitor environment data using this particular sensor and I have put together some golang code to interrogate it over i2c.

Not sure if your interested in external contributions at this stage, but may be handy for others.

I'm hoping on hacking on:

• finishing the OLED 96x96 implementation
• analog sensor now that the exp/io GPIO package should be stable
• planning of a generic solution for the GrovePi
• Maybe an oscilloscope if someone is interested in pairing with me on that

Anyone going to the conf and interested in some GoIoT hacking? /cc @rakyll @zankich @deadprogram

The sensor can trigger interrupts based on analyzed events. The type of events and the pin used to trigger these events can be defined as explained in the datasheet: http://www.farnell.com/datasheets/1670762.pdf

Unfortunately, the current state of exp/io/gpio doesn't allow us to add this feature. That said, we expect the gpio pkg to be soon ready. If you are interested in this issue, look at the gpio pkg, if he does support interrupt pins, then you can work on it.

func (o *OLED96x96) DrawBitmap(bitmap []byte) error { return nil } is not yet implemented. We might also want to add a DrawImg method that takes an image.Image argument