ESP8266 Community Forum

Hi

I have a BMP180 temperature/pressure board which I've hooked up to an ESP-12 using the code in the ECLIPSE setup for Windows. I've compiled many projects on this no problem. I've altered the code to use GPIO4 and 5.

#define I2C_SDA_MUX PERIPHS_IO_MUX_GPIO5_U
#define I2C_SDA_FUNC FUNC_GPIO5
#define I2C_SDA_PIN 5


#define I2C_SCK_MUX PERIPHS_IO_MUX_GPIO4_U
#define I2C_SCK_PIN 4
#define I2C_SCK_FUNC FUNC_GPIO4

When I first powered it up I got GPIO4 and 5 mixed and it came up with a predictable error message so I swapped them around. This time it booted up and said that the signature was wrong - instead of 0x55 it returned 0x5502 - reliably. So I altered the check to accept 0x5502 thinking it might be a version number issue... that starts up and returns debug info - but then never goes on to show temperature and pressure.

Has anyone seen this - I've connected nothing to GPIO4 and 5 other than obviously the module. Mine is the 5-pin job with both VCC and 3.3 connections - I've tried both. Makes no difference (everything is running on 3v3).

Booting...
BMP180 read calibration data...
BMP180_Calibration:
AC1: 7670, AC2: -1051, AC3: -14838, AC4: 33135, AC5: 24709, AC6: 17878, B1: 6515, B2: 36, MB: -32768, MC: -11786, MD: 2997

Ideas?

I'm not sure every pin can be selected ( muxed) as I/O for the built in esp8266 I2C hardware engine. You can bit bang I2C if necessary to GPIO4 and GPIO5.
I'm comfortable with MicroChip MCU documentation.....there is great detail from Microchip on electrical engineering ( the actual hardware )...perhaps this is available for the esp8266. The information for the esp8266 is about software mostly...like with PC's where the hardware capabilities are abstracted to the point of insignificance.
It is true the esp8266 bridges a world of ridiculous code lengths in which multi gigahertz CPU's shuffle electrons for coders to a GPIO pin that toggles a LED.
The issue with code length is that it creates latencies in megahertz MCU's like the eps8266 that can cause timing problems for real time interfaces. MCU's address this with interface engines that run separately (though they often share a common clock) and run in parallel with the bloatware coding so the data can make it through the interface in a timely fashion. In bound data can interrupt the bloatware to ensure data is digested before new data arrives. In this way the bloatware doesn't hold external devices hostage to long code lengths.