MicroPython Forum (Archive)

The WiThumb is a USB-powered device with ESP8266 and some sensors; see https://funnyvale.com/withumb/

I've managed to install and run MicroPython on it; see https://koodaamo.wordpress.com/2016/12/ ... mb-on-osx/

The temperature sensor is a common I2C - accessible MCP9808. But I am not familiar with i2c; all the i2c reads seem to return empty data (zeroes). I instantiate i2c with pins 4 and 5 and try to read from address 0x1F, registers 5 (temperature data), 6 (manufacturer id) and 7 (device id). But everything returns zeroes.

is there something I should do prior to trying to read data, with I2C? The firmware is fairly recent, from http://www.kaltpost.de/~wendlers/micropython/

What does "i2c.scan()" show?

deshipu wrote:What does "i2c.scan()" show?

A whole list of values, maybe 25 or so of them. Including 0x1F and 0x18 (well, their integer representations). Should it return so many? Given that WiThumb does not have anywhere near so many sensors, it kind of surprises me... I can retry and paste them here if that is useful?

Have you tried reading from address 0x18?

The Adafruit breakout board for the mcp9808 shows the default address as 0x18:

https://cdn-learn.adafruit.com/download ... -guide.pdf

jpj wrote:Have you tried reading from address 0x18?

The Adafruit breakout board for the mcp9808 shows the default address as 0x18:

https://cdn-learn.adafruit.com/download ... -guide.pdf

For WiThumb, the address is 0x1F. I've confirmed that from both the schematics and the Arduino C code provided by WiThumb author. I've also confirmed the C code works. But thanks for the suggestion - I did actually try 0x18 originally, as well, before figuring out the correct address.

If you get so many addresses from the scan, that may indicate a problem with the data lines. Try using stronger (smaller value) pullup resistors on your data lines, and try with a smaller speed of the i2c clock, for instance with freq=100000.

The WiThumb is an integrated piece so I cannot change resistors, and it works when I run the C code I referred to, so hardware is ok. I tried many different frequency values passed to the I2C constructor, ranging from 500 to 5000000. The Withumb crashes with too low (~500) value, otherwise it returns this list of values:

[8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119]

deshipu wrote:If you get so many addresses from the scan, that may indicate a problem with the data lines. Try using stronger (smaller value) pullup resistors on your data lines, and try with a smaller speed of the i2c clock, for instance with freq=100000.

That output basically means that you got an ACK for each and every address the scan is checking. That usually means that the data line is held low all the time.

I wonder, perhaps the C implementation of the I2C master enables the internal pullups on the pins, and thus manages to communicate without external pullup resistors?

I would also make sure that you didn't switch the SDA and SCL pins in your I2C class initialization.

Yet another possibility is that one of the sensors goes into an error state of some kind and holds the data line low. I know that the WeMos motor shield does that.

Looking at the schematic of the WiThumb, I can see no pullups on the I2C lines, which makes the theory about internal pullups sound plausible.