Interesting, that the Wire library in the Spark Core doesn’t work for the AM2315 the same way as on an Atmel . I haven’t yet started wiring my AM2315 up to my Spark Core yet, but I did previously wire it up to an Electric Imp and it’s been running for over a year. The Electric Imp is also driven by an ARM Cortex M3 like the Spark Core, but does not have an Arduino-like API. I suspect, however, that since the Imp delegates I2C to the M3’s hardware, there may be more similarities in the way that I2C works on these two devices, compared to an actual Atmel driven Arduino.
When I started with the Electric Imp, I tried to port the Arduino code over, but couldn’t get the device to function that way.
Then, I stumbled across this posting:
wIth code that did work for AM2315 using the Imp’s I2C stack.
Most of the code is the same, what looks like a direct port from C to the Squirrel language that the Imp uses, but there are a couple of key differences in the way the initialization sequence works.
The first is that the address of the device is bit shifted by 1 place (0x5C << 1), but may just be a difference in the way the Imp API works. The Wire library probably does this internally. In 7.2.4 of the datasheet, this seems to be why they send 0xB8 in the example transmission, since 0x5C << 1 = 0xB8.
Then, the initialization sequence is different. It sends a 0x00 to wake up the bus (without a delay) rather than doing an empty write (which I think is that the Wire.beginTransmission() followed immediate by Wire.endTransmission() will do). 7.2.4 of the data sheet cryptically says “if the host is a hardware I2C, you do not need to wait, to wait for hardware I2C automatically”.
After this, the code then sends 0x03 0x00 0x04 the same as the Arduino code, but waits 150ms rather than 10ms. 7.2.4 of the datasheet indicates a wait time of 1.5ms, so this may not be significant.
The remainder of the reply processing is the same.