Closed structure7 closed 8 years ago
The ESP8266 should work with any I2C sensor you can throw at it – just use the same Wire API calls you’re used to. There are a few differences: Pin definition: The ESP2866 doesn’t actually have any hardware I2C pins – those labeled on the Thing are the default, but you can actually use any two pins as SDA and SCL. Calling Wire.begin() will assume pins 2 and 14 are SDA and SCL, but you can manually set them to any other pin by calling Wire.begin([SDA], [SCL]).
From https://learn.sparkfun.com/tutorials/esp8266-thing-hookup-guide/using-the-arduino-addon
Same forum bastards, but new convo: http://www.esp8266.com/viewtopic.php?f=13&t=3129&start=10
Not really super helpful, but interesting reading perhaps: https://github.com/esp8266/Arduino/issues/1025
Look at chat starting at May 21 2015 19:26: https://gitter.im/esp8266/Arduino/archives/2015/05/21
and more
https://gitter.im/esp8266/Arduino/archives/2015/06/05
also, if you re using the adafruit library, even if you set pins with Wire.begin(0, 2); it overrides that in the lib with the defines from pins_arduino.h. try Wire.pins(0, 2); at the beginning of your sketch and then just display.begin(SSD1306_SWITCHCAPVCC, 0x3C);
Wuahh... 12E "pin translations," but... what is this pins_arduino.h, and can I use it? https://github.com/esp8266/Arduino/blob/master/variants/nodemcu/pins_arduino.h
(Seems like that's used here https://github.com/adafruit/Adafruit-SSD1331-OLED-Driver-Library-for-Arduino/blob/master/Adafruit_SSD1331.cpp)
Try using "i2c scanner" example. Maybe that will do something for me, like give an address (think I know this already) but maybe also reveal some wonky pin numbering (this doesn't seem to find pins): https://github.com/mcauser/i2cdetect
Another way to define Arduino friendly names to the ESP8266 GPIO pins is to use the C/C++ pre-processor directive #define as shown here:
define D0 16
define D1 5 // I2C Bus SCL (clock)
define D2 4 // I2C Bus SDA (data)
define D3 0
define D4 2 // Same as "LED_BUILTIN", but inverted logic
define D5 14 // SPI Bus SCK (clock)
define D6 12 // SPI Bus MISO
define D7 13 // SPI Bus MOSI
define D8 15 // SPI Bus SS (CS)
define D9 3 // RX0 (Serial console)
define D10 1 // TX0 (Serial console)
The advantage of using the #define commands is that they use up no memory in the compiled sketch. Feel free to strip out the comments as well.
I have a WeMos/LoLin NodeMCU that I bought a week ago and have been playing around (having played with the WeMos D1 board for a few weeks earlier). In testing the NodeMCU, I found out that the RX0 and TX0 pins are on D9 (GPIO3) and D10 (GPIO1) and they were not give names like D0 and D1 because these 2 pins are essentially reserved for Serial console communication. So, of the 11 GPIO pins (and ignoring the 5 GPIO pins used internally by the ESP8266 SoC (i.e. GPIO6, 7, 8, 9, 10 & 11)) that leaves only 9 GPIO pins which conveniently falls within the range of D0 and D8, and so were labeled this way.
The I2C Bus signals SCL and SDA have been assigned to D1 and D2 (GPIO5 & GPIO4) while the four SPI Bus signals (SCK, MISO, MOSI & SS) have been assigned to GPIO pins 14, 12, 13 and 15, respectively). That leaves just 3 pins unassigned D0, D1 and D4. Not much to play with. I guess we need to focus on I2C and SPI compatible devices when interfacing modules to this NodeMCU board.
However, the speed of the ESP8266 and convenience of WiFi should make this a popular alternative to the Arduino Uno and Arduino Nano. Now on to reliability testing...
Probably nothing special, but piling on: https://github.com/cmmakerclub/ESP_Adafruit_SSD1306
I could cry. Finally solved it! The reset was "fouling" my pin 4... any other pin choice and I probably would have been fine! Therefore:
#define OLED_RESET 0
This change to 0 did it!
Think I'm getting warm:
From https://www.arduinotech.cz/inpage/nodemcu-wifi-modul-s-esp8266-496/
Takeaway: Is there any conflict between OneWire.h (used for Dallas) and Wire.h?