Reworking the AI Thinker T5 – Part VI – Blinkenlights!

Okay, now we get to the bit that everyone’s been waiting for; we’re going to connect up the LEDs.  Yay!

If you remember back to the original description of the board, I mentioned that there were three LEDs (next to the ESP8266 module) which, with their current-limiting resistors, were arranged in a vaguely spoked shape (and as there are only three spokes, it’s more like an old-fashioned water valve than a bicycle wheel).  Unfortunately, the folks who designed the board put the LEDs on the inside of the spokes (with the resistors on the outside), which kinda’ spoils the effect …and also makes them a little more difficult to wire up, as the cathodes are all so close together.  In an earlier instalment, I added a short jumper wire between GPIO5 of the ESP8266 and the cathode of the blue LED (which is the one closest to the ESP8266), simply so that I could have some indication that the module was powered on and operational.  As with most quick-and-dirty hacks, it has become permanent and, despite the fact that it’s butt-ugly, I’m not planning to change it.  That leaves the two others.

GPIO0 and GPIO2 connections

Going back to the photo of the wiring to switch K1, you can see the short jumper to the blue LED quite clearly.  The spoke pointing directly at switch K2 is a green LED and the one pointing  directly at the edge of the board is a red LED.  It’s also clear from the photo that soldering wires to the cathodes of the two other LEDs would be quite challenging.  Luckily, the drive for all three LEDs came from the QFP 8051 chip, so the cathodes of all three are wired to the pads where that unlucky device used to sit.  Equally luckily (for my shaky-handed soldering), the pad for the blue LED is between the other two and, as the blue is already connected, it gives us a little bit of extra clearance to play with when soldering wires onto the green and red pads.  The original schematic didn’t identify which LED was which, but our updated (ie:- scribbled on) version has them labelled. As you can see, the drive for the red LED is wired to pad 26 and the green to pad 28, so all we need to do is run wires from spare GPIOs on the ESP to those pads and update our test progam to use them.  We’re going to use the adjacent GPIO14 and GPIO12 as our drive pins (GPIO4, on the other side of the module, is also still free, but we’re going to use that later for the connection to switch K2).  For GPIO14 and GPIO12, we’ll run the wires around the rather bulky (and, for us, badly placed) smoothing cap sited between the ESP module and the edge of the board, under the DHT11 sensor and directly to the QFP pads (which are on the DHT11 side of the footprint).  Again, use super-glue or tiny bits of hot-glue stick, melted with the soldering iron, to hold these (quite long) wires down to the PCB.

After completion, here’s what my board looked like. It’s starting to get a little bit crowded around that SMD capacitor, but there’s only one spare GPIO left on that side of the board anyway, so we’re not going to be adding too many more wires.

Updated code is available from the GitHub repository.  The new file is named DHT11_Test_Blinken.ino and, in normal Arduino style, must be moved into a directory named DHT11_Test_Blinken to enable compilation.  Note that the user_config.h file needs to be available in the same directory and that configuration changes specific to your network must be made in that file prior to compilation (ie:- your access-point SSID and password, your MQTTserver hostname and port-number, etc).

Note that if you’ve already completed the previous rework to connect switch K1 to GPIO0, you can now initiate programming mode on your T5 by turning off the power, holding down K1 and the switching the power back on again.  You should be able to release K1 as soon as the board has powered up.

After programming with the “Blinken” code, the coloured LEDs will display a very brief “spinning wheel” at power-on and at all subsequent deep-sleep wake-ups.

The next instalment will cover adding K2 as a “mode control” switch, to change the function of the board at power-up time.

Reworking the AI Thinker T5 – Part III

In the previous post, we did some simple, straightforward modifications to get the “Black board T5” working using the ESP8266 alone.  In this part, we’ll go over a very simple application to demonstrate that the ESP8266 is alive and kicking and will download a program as normal (in program mode) and will also run that program (Duh!) and communicate with the DHT11 temperature/humidity sensor.

But first, as I mentioned in Part-II, if you have (as I do) a 5v-only USB to serial converter, you’ll need to add a 5v-to-3v3 voltage converter for the TX and RX pins, otherwise there’s a good possibility that the magic smoke will escape from your ESP8266 module.  I’m using the tried and tested MOSFET conversion method, which uses a single, N-Channel MOSFET (and two resistors) in each line to do the conversion.  You can buy these as 4-way converters on eBay for about $1 each, but the circuit is so simple that I tend to throw mine together on odd scraps of stripboard whenever I need one. For the T5 board, there’s some hardware already available which makes the stripboard method even easier.

As you’ll have noticed, there’s a nice, 5-pin connector off to one side of the board which was apparently intended as a camera port.  There aren’t

too many details available on what camera, or what the intended use actually was, but the important point (for us) is that pin-1 on the connector is GND and pin-5 is 3v3, with the three middle pins now free (as we’ve already removed the STC QFP micro to which those pins were connected).  By a happy coincidence, we need just exactly that number of pins to attach our 5v-to-3v3 converter (TX, RX and 5v, in addition to the existing GND and 3v3).

I’m going to show you how I implemented this connection, but as always, there are several different options available to you and you should choose whichever one is the easiest or the best match to your particular circumstances.  Some of the options you might want to consider:-

• Find a matching plug for the camera socket and use it.
• Remove the camera socket and replace it with pins or flying leads.
• Ignore the socket and solder flying leads directly to existing pads.
• Butcher the socket, because we just enjoy inflicting damage on this board (insert mandatory evil chuckle here).

Of course, I chose the last option (but in the interests of completeness I should also mention that I removed the socket from the board first,

Nekkid camera socket

thinking that I would replace it with straight pins, before realizing that that was extra work and not so much fun!).  I should also mention that removing the socket is quite difficult, so I wouldn’t recommend that particular option.  Note the odd silkscreen pin descriptions which were hidden under the socket.  It seems that “CG”, “CT”, “CR” and “CV” probably stand for “Camera Ground”, “Camera Transmit”, “Camera Receive” and “Camera Volts”, respectively.

Anyway,  after consuming about twenty odd cups of tea, I had a rare flash of inspiration (in addition to the ten odd flushes) and realized that  I could just snip the top and side plastic shielding away from the existing plug and solder the chunk of stripboard with the voltage converter circuit directly to the pins (you can do this without removing the socket from the board).  Then, on the reverse side of the T5 PCB, I simply jumpered the TX and RX pins for the ESP8266 to the “WIFI_TX” and “WIFI_RX” jumper pins (described in Part-II).  The advantages of this method are, further sadistic butchery of the T5, no flying leads and the converter board is always attached to the place we want it (rather than having to search through piles of junk other projects to find it each time we want to reprogram the board).

The circuit for the MOSFET voltage converter can easily be found on-line by doing an Oogleg search for “MOSFET voltage level converter”.  Neither the MOSFET type nor resistor values are particularly critical in this particular application.

Okay, so we now have a board which we can program, so we need to write some software to drive it.  I’m using the Arduino-ESP core, simply because I find that it works reliably at fitting programs into the limited memory of the ESP8266 without too much faffing around on my part.  I’m not an Arduino guy (don’t own any boards, or chips) and I’m definitely not keen on the Arduino IDE, but the rest of the set up just works reliably for programming ESP8266 modules.

Here’s some code which is just a tiny bit longer than the absolute minimum to get you going with your newly modified T5 board:-

/*
* $Id: DHT_Test.ino,v 1.3 2015/12/11 02:09:02 anoncvs Exp $
*
* Test program for the AI Thinker "Black board T5", after
* modification to remove the 8051-based QFP micro and wire
* the DHT11 sensor and blue LED directly to the ESP8266.
*/
#include "DHT.h" // We're using the Adafruit version.

// DHT dht;
#define LDELAY 10 * 1000 // Loop delay (10 seconds).
#define DHTPIN 2 // DHT11 sensor on GPIO2.
ADC_MODE(ADC_VCC); // Required for correct operation of 3v3 measurement.
int BLED = 5; // Our WiFi debug LED is on GPIO5.
float temperature = 0;
float humidity = 0;

DHT dht(DHTPIN, DHT11, 15);

/*
* Turn on the blue WiFi debug LED for a short
* flash. Note that on the T5 board the LED is
* driven by a low-side switch.
*/
void BFlash() {
digitalWrite(BLED, LOW);
delay(80);
digitalWrite(BLED, HIGH);
}

/*
* Try to get a valid reading from the DHT11 sensor
* (not always easy).
*/
void getSensorData() {
temperature = dht.readTemperature();
humidity = dht.readHumidity();
while ((isnan(temperature) || isnan(humidity))
|| (temperature == 0 && humidity == 0)) {
Serial.print(“!”);
delay(500);
temperature = dht.readTemperature();
humidity = dht.readHumidity();
}
Serial.println(“”);
}

void setup() {
Serial.begin(115200);
delay(500); // Pause for boot-up crap.
pinMode(BLED, OUTPUT); // Ensure our blue LED driver pin is an output.
Serial.println();
Serial.println(“Status\tHumidity (%)\tTemperature (C)”);
dht.begin();
}

void loop() {
float vdd = ESP.getVcc() / 1000.0;
delay(LDELAY);

getSensorData();
BFlash();

Serial.println();
Serial.print(“Temperature: “);
Serial.print(temperature);
Serial.print(“c – Humidity: “);
Serial.print(humidity);
Serial.print(“% – Voltage: “);
Serial.print(vdd);
Serial.println(“v “);
}

Note that this code uses the Adafruit DHT library (please send them some of your custom  — if you happen to live on a favoured continent, you can get an Adafruit ESP8266 “Huzzah” for just about the same as you’d spend on the POJ T5 board).  This simple program doesn’t use the wireless capability of the ESP8266 at all; it just sits in a loop and squirts the temperature and humidity readings from the sensor out to the serial port every ten seconds (it also displays the current 3v3 line voltage as an added extra).

Because the T5 uses the DHT11, there’s also a while() loop in the getSensorData() function which will basically discard the (fairly frequent) bad readings returned by this particular sensor.

While we’re on the subject of the DHT11, you’ll notice when you fire up your board and start using it, that the sensor starts to read high after a few minutes.  This is because of the heat generated by the ESP8266 (which the DHT11, by a poor design choice, is sitting right next to).  You can alleviate the effects somewhat by lifting the DHT11 from its flat-on-the-board position to standing vertically, instead.  It will still read a little high (because this simple program doesn’t put the ESP8266 to sleep), but it will be noticeably better than before.

Finally, again, because the ESP8266 doesn’t sleep with this simple program and because the red, power LED is always on, the batteries will last barely 24-hours if you leave your module switched on permanently.  We’ll do something about that next time.

 

…and another one from AI Thinker

Hard on the heels of the weirdo “Black board T5” development board, CNXSoft just published a news byte on the new “ESP-14” module from AI Thinker.

Guess what?  The ESP-14 is just basically an ESP-12, with an STM8S003F3P6 microcontroller strapped on (and yes, that’s yet another, different microcontroller than the one which is on the “Black board T5”).

AI Thinker ESP-14 Module Pinout

The pins on the module are basically (with the exception of GPIO-00) the STM8S pins, not the ESP8266 pins.  An interesting point with the module pins is that there’s a separate VDD pin for the ESP8266, so it looks as though there’s provision for external control of the power (which makes sense for battery operated designs).

The slightly-better-than-the-previous-weirdo news is that the microcontroller on this board looks a little more sensible (in most respects) than the off-the-wall STC15L2K32S2 on the BBT5.  It (the STM8S) is a Harvard architecture device with 8KB of Flash, 1KB of RAM and 128B of EEPROM, which should look fairly familiar to AVR and PIC folks.

It still raises the question as to why AI Thinker believe we’re all going to rush out and buy a relatively unknown micro and re-tool (both hardware and software) yet again, after all of the pain we’ve gone through over the past year getting a workable ESP8266 environment in place.  If this had hit the marketplace when we were all pulling our hair out a year ago and if it had been an on-board AVR instead of the STM8S, then they might have had a winner on their hands.  As it stands … Double-Duh!, again.

This one’s quite neat!

One of my long-standing favourite shops in Tokyo’s famous Akihabara district, Akizuki Denshi, has just started selling the WROOM-02 (that’s Espressif’s own version of the ESP-13, just in case you haven’t been paying attention) with an adapter PCB kit which brings out the pins to a breadboard-friendly connection.  It’s quite novel.

Akizuki Denshi WROOM-02 to 2.54mm DIL adapter board

The kit comes with the WROOM-02 already soldered onto the board, but the header pins (although included in the package) need to be soldered to the PCB by the purchaser.  The kit (including the WROOM-02) is priced at a very reasonable 680-Yen (that’s about $5.70) plus shipping.  Unfortunately, they don’t ship internationally.

They are also selling the bare PCB as a separate item for just 120-Yen ($1.00).

As you can see from the photo of the bare PCB, all of the pins are broken out to the adapter (including the three, separate grounds).  As far as I can tell from the photos and from the text, there are no pull-ups or pull-downs; just the pin connections and nothing else.

Bare PCB

Akizuki have a long history of producing kits and PCBs for the hobby market in Japan and a look at the “kit wall” in their shop is a good, barometric indicator of what’s hot in the embedded community here (of course the challenge is actually managing to elbow your way in there to be able to see it).

‘nuther new something in town …you can safely ignore it!

AI Thinker have obviously been listening …but the question is, to whom.  They’ve just come up with something which they’re calling the “ESP8266 Black board T5” (their capitalization, not mine).  It looks really interesting at first glance.

AI Thinker “Black board T5” development board with attached battery box

[Update:-  I ended up reworking this board to make it somewhat functional.  If you’re comfortable with a soldering iron, you might be interested in these notes]

There’s a relay and a couple of screw-down connectors at one side of the board and what’s obviously one of the older  (blue) DHT11 temperature/humidity sensors on another side, sitting next to an ESP13/WROOM-02 module.  Between the relay and the DHT11 is a barrel-connector for DC input, but the unit also comes with a 3-cell (AA size) battery box attached via short flying leads (the board itself is just a little bigger than the battery box).  There’s a beeper on the board and there are three LEDs arranged in a vaguely spoke (as in bicycle wheel) shape.  In addition, there are two mini “tact” switches, a couple of jumpers, a slide-type on/off switch and, sitting like a spider in the middle of its web, a mysterious, 32-pin, QFP package chip.  Etched along the edge of the board is “ESP822_IOT_DEMO” (sic) and also “AI-CLOUD INSIDE”.

As usual with the on-line auction site vendors, there’s b’grall useful information on any of the pages which I could find (and as the auction sites advertise it as an “ESP8266 Serial Development Board” it’s also next to impossible to find any useful information on the web, either).  Anyway, just looking at the board I thought it had to be worth the $10 asking price, just in parts alone.  With a bit of luck, the mystery chip might turn out to be an I2C expander or something equally useful.  Throwing caution to the winds (poor old Caution!), I added a single unit (Caution must have crawled back home again while I was surfing dBay) to the next order I made for other odds n’ends.

Tum-de-dum-de-do.  Wait for a couple of weeks.  Odds n’ends arrive, along with da’ board.

AI Thinker “ESP8266 Black board T5”, with red LED visible just to the left of centre.

Hmmm…  Don’t recognize the number on the top of the mystery chip.  Never mind, throw in some batteries and slide the switch to “On”.  A red LED (which I hadn’t noticed in the pictures) lights up and, after a slight delay, the board starts to emit an annoying “Do something within the next few seconds, or I’ll explode” kinda’ beep.  I press one of the buttons.  It still beeps.  I press the other button.  It still beeps.  I switch it off, hold down one of the buttons and switch it back on.  It starts to beep again.  Same procedure, but other button.  Ahah!  a single beep and then blessed silence …for about a second, then it starts to beep again.  I rip the batteries out and throw the whole thing in a drawer (I was sorely tempted to throw it on the floor and stamp on it, but I thought I might damage the floor).

Back to the web (as there was b’grall documentation in the package, of course) and I resort to a Oogleg image search.  Oogleg’s image processing may be wonderful, but it seems to think that this PCB is a dead-ringer for all sorts of weird and wonderful stuff on the web that just happens to have a black PCB.  I finally find a link to AI Thinker’s forum and a thread which has some links to documents (Yay!), one of which seems to be an English PDF (double Yay!).

My yaying turns out to be a little premature.  The English documentation is limited to the schematic and it’s a fairly useless one, at that.  Many of the components evident on the board aren’t present on the schematic at all, labelling is haphazard, parts are wrongly identified (the 32-pin QFP is labelled as an STC15L2K16S on the schematic, but the part on the board is an STC15L2K32S2 [see below], the sensor is identified as a DH11, but the part on the board is definitely a DHT11) and plugs, sockets and jumper blocks are all depicted as unidentified rectangles.  One thing that does stand out immediately though, is that most of the GPIO pins on the ESP8266 are unconnected.  Uh-oh!

Original Schematic

A P-Channel MOSFET (top R/H corner of the schematic) gives another clue to what’s going on here.  The drive signal is labelled “WIFI_VCC”.  It’s a supply-side switch for the ESP8266 power.  The board is battery powered and it looks as though the ESP8266 is only powered up when a network connection is needed (and I recognized this simply because I’m doing the same thing with one of my ESP8266 projects, but using a DS3231 RTC module to drive the power switch).

So, it turns out that AI Thinker have produced a board which has a “master” microcontroller and is using the ESP8266 simply as a network interface.

Next to the on/off slide switch there’s a three-pin connector (barely visible in the photo above – it’s slightly above and to the left of the DHT11) with the silkscreen label “R-G-T”, which appears to be the serial port for the microcontroller (not for the ESP8266).  I pulled the unit out of the drawer again just long enough to connect up the pins and go through the press-beep-disconnect routine a few more times at various baud rates.  I didn’t ever get any indication of any output at all in the terminal window.  Zilch!  Nada!  Nutt’n!  At the same time I fired up a WiFi scan on one of my access points.  I could quite easily see my neighbours’ access points going up and down, but no indication at all that the ESP-13 on the board was ever powered-up.  Back in the drawer wi’thu useless burger!

I might possibly drag the thing out again and have a poke around with a multimeter, but not before I’ve de-soldered that bloody annoying beeper.

The microcontroller chip on the AI Thinker “Black board T5”

As far as I can tell from the scant information available for this microcontroller part number available on the web, the chip is an 8051 derivative, with 32K of onboard flash memory.  I haven’t used an 8051 chip in twenty years and, although I’m sure there are some folks out there who will be positively salivating at the thought of an 8051 paired with an ESP8266, there will most certainly be many thousands more who will be scratching their heads and saying “WTF?”.  I’m not (and probably never will be) an AVR/Atmel kinda’ guy, but why AI Thinker would AI Think it a good idea to produce a board for the hobby market with such an odd-ball chip is beyond me.  If they’d dropped in an ATtiny85, a Propeller, an MPS430, a PIC18F/24F, or just about any low-end ARM chip they would have had the (ESP8266) world beating that proverbial path to their door.  As it is, they’re destined to get a big, red “FAIL” stamp splattered across their collective foreheads.  Anyway, if you’re at all interested, I finally found the data sheet for the chip on STC’s web site (no thanks to their total lack of indexing or search function and the quiet inclusion in one data-sheet — with a single processor ID as the only title —  of 18 different chips).  The highlights are, yes 8051 based, 32KB of flash, 2KB of SRAM,  29KB(Eh?!?) of EEPROM, 2 x UART, 3 x PWM, internal clock and 8-channel, 10-bit A-to-D.  If all of that lights your fire, then this is the board for you (and I’ll sell it to you …cheap!).

Hold on just a second; I need to go and add a “Double Duh!” category for this one.

Update – In an effort to introduce some semblance of balance into this post (and especially to note that I’m not, generally “anti” AI-Thinker), I’d like to point you at a couple of articles on one of their other boards, which actually is something of a bargain!  Just about the only thing it has in common with the “T5” is a long and overly complicated name, but you should definitely keep an eye open for the ESP12-based “Yellow Development Board”.  Apart from anything else, it has lots of nice flashing LEDs and you don’t need to resolder anything to get them working.

SDK I2C Code. Today’s “Duh!” Story.

This entry is here as a helper (hopefully) for any other poor soul banging their head against the wall of Espressif’s I2C “master” implementation.  <TL;DR Spoiler>  When using the i2c_master.c code supplied with the IoT SDK, you must call i2c_master_gpio_init() before any other I2C functions in your code (and, obviously, your GPIOs need to be correctly defined beforehand).

ESP8266-03 with DS3231 module and DS18S20

I’ve been trying for days to get I2C working with an ESP8266-03 and a DS3231 RTC module (the el-cheapo, middle-kingdom one with the AT24C32 memory on the same PCB).  This was starting from scratch with I2C on the ESP8266 for me (I’d previously put together a trio of PICs talking to each other over I2C without too much trouble, so I naively thought that the DS3231 should be a doddle).

Hardware wise, I had the DS3231 hanging off a 4v5 supply and the ESP8266 running from a 3v3 linear regulator, supplied by the same 4v5 source.  The reason for this is that I intend to make the unit into a self-contained, battery-powered data-logger and I want the DS3231 to be able to control the power to the whole shebang through a small MOSFET driven from the alarm output.  The I2C bus is run through a MOSFET-based level shifter to ensure that the ESP8266 pins aren’t over-driven.

As normal, on the software side I started off with TuanPM’s totally excellent MQTT package (and if you’re not using this already, you should be!) as a starting point for my new project.  I simply added the i2c_master.c and i2c_master.h from the Espressif (IoT) SDK into the tree, modified the GPIO settings in i2c_master,h to point to the ESP8266 default I2C pins (GPIO2 for SDA and GPIO14 for SCL), added a tiny calling function into user/user_main.c and compiled.  I flashed the ESP-03 with the RTC module attached and… nothing!.   Okay, quick check… Duh, my SDA and SCL connections on the stripboard were the wrong way round.  Okay, resoldered the jumper wires, double checked with the meter and we’re good to go.  And… nothing.  Again!  My output data resolutely remained at all zeros, but the DS3231 calls (using Richard Burton’s ESP8266-ready code) didn’t throw any errors.  Double duh!

I certainly had no reason to doubt Richard’s code.  He’d only just recently done this himself and has a blog about his ongoing projects that is definitely recommended reading for anyone playing with the ESP8266.  I did have reason to suspect that the hardware might be a touch on the dodgy side though, as the DS3231 module already has a pull-up resistor pack on the I2C lines and the MOSFET level-converter also uses 10k pull-ups to both the 4v5 and 3v3 sides.  Thus the 4v5 side had the DS3231 pull-ups and the level-converter pull-ups in parallel and I suspected that the bus might not be being driven hard enough to a logical “0” on that side because of it.  Back to the soldering station, off with the SMD pull-up pack (and, while I was at it, off with the red-LED and the coin-cell “charging” diode, too…  I don’t need an LED sucking extra current from the 4v5 battery pack and the charge diode, as has been noted in lots of places on the ‘net, is a positive danger when using a normal, non-rechargeable CR2032 in the RTC).  Reconnected and yes, I know you’ve already guessed it, bugroll again.  Sigh!

Back to the soldering station.  Ripped out the original RTC module and slapped in another one.  Bugroll, repeated.

At this point I was considering popping one of the RTCs into a PIC-based board, just to check that I didn’t have two dodgy ones, but on reflection, decided that the quickest and easiest next test was to use another I2C implementation instead.  I had already seen Nathan Chantrell’s ESP8266-enabled OLED project and remembered reading that he’d used Zarya’s I2C implementation to drive the display.  Nathan’s blog is another one of my favourites and he certainly doesn’t seem to get things wrong as often as I do, so off I went to GitHub again and pulled Zarya’s I2C code.  It’s basically just two files, the i2c.c and i2c.h, which replace the i2c_master files from the SDK implementation.  First glitch… that missing word, “master”.  Richard’s code calls the i2c_master_whatever() functions, a couple of which are not compatible, argument wise, with Zarya’s implementation.  Okay, “Cheat” is my middle name, so taking the laziest course of action I just rolled half a dozen, one-line wrappers to encapsulate Zarya’s code into i2c_master_whatever() functions.  The only minor change was to make the ack and nack separate function calls (Zarya’s code sensibly uses a single ack function and passes either a 0 or a 1 depending upon whether it’s actually an ack or a nack).  Flashed and… Hurrah!!  Three cheers!  Two pints of Guinness and a packet of crisps, please!  The module burst into life and sent real data.

Mostly it sent really bad data, but at least not just those boring old zeros any more.  The memory module obviously wasn’t writing data at all and the RTC was returning some really weird values for everything except the seconds value, but the internal temperature sensor in the DS3231 was sending sensible, accurate temperatures (instead of the previous, monotonous “Bit chilly in ‘ere, innit”).  Hmmm, verrry interestink!

Unfortunately though, this still left me in something of a quandry.  Now I knew my hardware was capable of working to some extent, but was the bad data a result of my inept programming of the wrappers, or did I still have a hardware issue of some sort, or (perish the thought) was Zarya’s I2C implementation incompatible with the SDK (which has been updated several times since Zarya originally published his code) or Richards DS3231 driver?  Okay, there are a couple of other I2C implementations out there and one of them, by EADF, implements a replacement i2c_master with a significantly easier method of specifying the GPIO defines than the original, SDK master (EADF is the guy who also brought us “easygpio”, so this should be no surprise).  Off to GitHub again.  “https://github.com/eadf/esp8266_i2c_master”. Download. change out the files. compile, flash and… bugroll again.  Aaaargh!  Now I’m starting to doubt my own sanity.  I trust EADF like a brother.  He’s never let me down where the ESP8266 is concerned.  What’s going on here?

I spent more time looking at the two implementations (Zarya’s and EADF’s) side by side to try and work out what was different and it eventually struck me that there was one extra function in EADF’s code which, while missing from Zarya’s, was also present in the SDK version —  i2c_master_gpio_init(). So I finally check the much maligned and utterly useless SDK documentation and, yes, there it is, labelled as “Function: set GPIO in i2c master mode“, nothing else.  Looking at the code itself, it’s obvious that the function does pretty much nothing, other than the all-important job of setting the GPIO pins to the correct mode for I2C (and Espressif have even helpfully commented their code with “//open drain” on those lines), before calling the I2C initialize function.  So, the documentation, despite it’s shortcomings, isn’t so utterly useless after all (just bloody useless!) and a quick edit of my calling code to replace i2c_master_init() with i2c_master_gpio_init() caused it all to spring back into life again… this time with sensible data coming from the RTC and the AT24C32 memory chip, too.  Yip-finally-ee!

Bottom line (same as the top one)…  When using the i2c_master.c code supplied with the IoT SDK, you must call i2c_master_gpio_init() before any other I2C functions in your code (and, obviously, your GPIOs need to be correctly defined beforehand).  Failure to do so will cause hours of frustration (this seems to be my standard state when trying to do almost anything with the ESP8266 nowadays) and will also cause your significant other (and possibly the neighbours) to complain about the unrestrained use of Anglo-Saxon and unwarranted cat kicking.

The right hand giveth….

First, the good news… Espressif have released an updated (as of June 1st 2015) documentation package on their web site:- http://bbs.espressif.com/viewtopic.php?f=21&t=412

My initial impressions (from the datasheet for the ESP8266EX chip and the hardware guide) is that the English language versions are very much improved from the early releases and definitely worth your time to download.  The datasheet especially now has several very clear, easy to understand tables, showing the pins by function.  This very much helps to reduce confusion as, for instance, if you want to use I2C you only have to scroll down to that section and deal with a table listing two pins (all you’re interested in).

Espressif ESP-WROOM-01 Module (Photo courtesy of Espressif)

The new revision of the datasheet certainly seems to have fewer instances of ambiguous wording and is generally much easier to read.  There seems to be a lot more useful information in there, too (but that may be because I’ve failed to keep up with the earlier published revisions).  The hardware guide has quite a bit of useful information on layouts and PCB design issues, as well as information on the ESP-WROOM-01 (that fabled beast with the normal-sized header pins).

And next, the not quite such good news… Espressif have released SDK 1.10 (and patches to it, already) and, as we are all now becoming increasingly and frustratingly used to, have broken just about everything in sight.  Again.

Initial reports are that existing code fails to compile with errors referring to the PULLDWN register settings for GPIOs.  These have apparently gone away completely.  The Espressif posting on the change states that, “Note: There are no pull-down functions on GPIO pad now, so we should never use these registers.  Add external resistance to pulldown the pin.“.  It is unclear to me whether the wording refers to all GPIO pins, whether the pull-downs were there originally and have been removed in later versions, or whether they were there originally and have just decayed over time.  The updated datasheet for the ESP8266EX chip says specifically, “Each GPIO can be configured with internal pull-up (except XPD_DCDC, which is configured with internal pull-down),…“, so there almost certainly is at least one pull-down, maybe, possibly, perhaps.

As usual, Pete Scargill is doing a great job of disseminating the latest information on what’s happening on the issues around this latest SDK (and his site is always worth a regular visit for ESP8266-related updates, anyway).

More, Useful C Code For The ESP8266

Richard Burton has a new-ish blog with some interesting, clock related stuff.  Half of the blog is devoted to his restoration of an actual, mechanical turret clock and the other half is a very nice collection of his C code for the ESP8266, mainly related to the DS3231 RTC.  As well as the driver for the DS3231 (and the EEPROM usually found on the same PCB with these devices), he also has a simple NTP client (for setting the time) and timezone support.

Definitely worth a visit!

Another ESP8266 board worth looking at…

Just a quick note here to draw your attention to Tracker-J’s v2 ESP8266 mains controller board.

Picture credit:- “Tracker J” @ http://www.esp8266-projects.com

This board has a nice little break-out for ESP-07 or ESP-12 modules on the L/H side and a standard MOC3041 zero-crossing, isolated triac driver on the right.  The ESP8266 side has a voltage regulator, pull-ups and a programming jumper.  The triac side is pretty much the standard circuit (including component locations for a snubber network) that we’ve all come to know and love over the years.  The bulk of the components are through-hole, with a smattering of SMD on the rear of the ESP8266 module side (but only two SMD resistors on the back of the MOC side).

The designer, Tracker-J, has a couple of photo’s of the board split down the middle to make discrete ESP8266 module and mains power control boards, but there are no holes or slots at the cut point, so you’ll have to get out your hacksaw or guillotine to get the two halves apart.  To be honest though, the attraction of the board is its functionality as a simple, generic, wireless mains switch, so I don’t envisage too many people reaching for a hacksaw.  Having said that, the boards are available in batches of 10 from Dirty PCBs, so it might be nice to have a snappable version to allow re-purposing of any excess units.

My “wish list” for v3 would be the addition of slots/holes to make the two halves snappable, mounting holes (three would do), the repositioning of R6 from the cathode lead of the MOC to the ESP8266 side of the “CMD” jumper on the anode side and the addition of a silk-screened skull-and-crossbones “DANGER!” label on the mains control side.  Before putting it up on Tindie “to make a (small) fortune”,  Pete Scargill suggests that it would also benefit from a barrel or micro-USB connector to enable the use of a cheap phone charger as a low voltage PSU.

All in all though, version 2 is still one of the better ESP8266 boards out there.  Check Tracker-J’s site for his other, ESP8266-related projects, including adding a DS3231 I2C RTC board and a perfboard breakout for the ESP07/ESP12 modules.