If you haven’t seen it already, I’d recommend you pop over to Hackaday and read through their latest “Hands On” article on the ESP32 …including the comments. Both “igrr” (Ivan Grokhotkov, of ESP8266/Arduino fame) and “Sprite_tm” (Jeroen Domburg, of libesphttpd fame), who both actually work for Espressif nowadays, have joined in the conversation to answer the questions which the HaD crowd have and straighten out any misconceptions. It’s turning into one of the longest, most interesting and on-topic threads that we’ve seen for quite a while.
Looking for a breakout board for that ESP32 module (whenever it actually arrives)? OSH-Park and Ben (over at HydraBus) have you covered. A week or so ago, Ben posted the rev 1.1 board design of his HydraESP32 on OSH Park’s shared projects. There isn’t too much detail on what has changed since rev 1.0, but I suppose we can assume that he’s worked some of the kinks out of the original prototype.
The board is designed to be mounted either on top of, or below, the HydraBus board, so there are footprints for the ESP32 on both sides (but only one should be used, obviously). The white line down the middle is a cut line, for those users who just want an ESP32 breakout board without the HydraBus connectivity. Unfortunately, the extra real-estate taken up by the HydraBus section means that the design will cost you $17.35 (for three) from OSH-Park, which is fairly expensive …but then again, right now your ESP32 options are a bit limited. Business opportunity, anyone?
Just a quick note here to raise a flag concerning module compatability, functionality and design.
I would guess that most people reading this probably know already that the company Espressif is the manufacturer of the ESP8266 chip and the producer of a couple of the reference designs to support it. Most (though not all) of the actual modules (the PCBs with the ESP8266 chip and additional components required to support it) are produced by other companies. The most prolific producer is “AI Thinker” and we (the hobbyist community) have a lot to thank them for — the low retail cost of the modules for one thing and the wide variation of different available designs for another. Equally so, there have been some fairly big bumps along the road, with modules getting into the supply chain with magic smoke issues (the “self healing” LED current limiting resistor problem) and confusion from both the vendors and recipients of various modules when the item received was markedly different from the item ordered (to be specific, I’m talking about the ESP-12 variants here, not odd vendor miss-ships).
The lack of useful documentation has been one of the main bugbears with the ESP8266 from the very start and AI Thinker have been a fairly major player in that particular field, even if you do happen to read Chinese.
Well, unfortunately it looks rather as though it’s happening again. Danny Von Lintzgy has left a couple of comments over at Pete Scargill’s blog noting that his product is pretty much dead in the water for the time being, as the latest batch of ESP-06 modules has different connections from all of those which he had received previously (the ESP-12 all over again). Danny says “It seems the new variant has three of the corner pads connected to pins, where previously all four corner pads were connected to ground“. That’s a pretty major change to have happen without any notification or hints (even the ESP12E at least had visible, extra pads).
So, if you’re using ESP-06 modules, please take note of Danny’s warning and be very careful with any new modules you purchase. It doesn’t sound like a magic smoke issue, but if your new ESP-06 won’t boot and won’t program, this could be the reason.
Update – Danny has reported that AI Thinker support got back to him with the news that there are currently three versions of the ESP-06 out there. The first is the older original, then (most worrying) there’s a not-quite-right version of the new design (which apparently has a problem with one of the resistors — but no news yet as to what sort of issues, if any, this errant resistor causes) and the last is the new design with the resistor problem corrected. Apparently, the original and the newer versions have a slightly different AI Thinker logo on the outside of the RF shielding with (I believe) the newer versions having WiFi-style radio waves radiating from the head of the character which makes up the stylized “I” of the “AI”.
Probably everyone else in the universe knows this one already, but there’s an eclectic (and long) collection of ESP8266-related links, compiled by AdamNovak2015, over at flipboard.com/@adamnovak2015/esp8266-hfo47ts2z.
I’ve mentioned Eldon R. Brown previously (see the ESP-13 “New kid on the block” updates section) as he’s making leaps and bounds with both the hardware and software associated with the ESP8266. One of his projects worth looking at is his ESP8266 server farm.
It consists of three ESP8266 modules plugged into a breadboard, along with a breadboard power supply. Eldon has put the farm on-line and you can access it at:- http://dc02.ebcon.com:8160 .
Even more impressive than the hardware are the graphics Eldon has managed to shoehorn in there, utilizing SVG. His code is already up on GitHub so you can see how he does it over there.
Back on the hardware side, Eldon has been designing adapter PCBs to enable various models of ESP8266 to be plugged into breadboards without blocking all of the connector holes (a common problem with almost all of the existing adapters). His latest version is one for the ESP-13/WROOM-02 module and it uses offset, SMD pin headers to allow the ESP module to fit a normal DIL-18 IC header space. It looks like a winner and it’s available now as a shared project board from OSH-Park.
All in all, it’s definitely worth ten minutes of your time to check out the good stuff which Eldon has available on his blog (and that’s not even mentioning all of the HAM-related stuff [amateur radio, not dead pigs]).
Pete Scargill has posted a note to let people know that there’s another ESP-12 variant available from AI-Thinker. It’s designated as the “ESP12E” (the “E” presumably denoting “
Extended” “Enhanced”) and it differs from the previous versions in that even more of the ESP8266 chip pins are broken out to pads along the bottom edge of the module. There is a paucity of information available on just how to use these new I/O pins as yet and, to be honest, early indications are that this module might not be too useful for the average user. It looks as though the pins are the multiplexed serial data and clock for the on-board memory, which might make them unattractive unless you really, really need I/O at the expense of everything else. However, time will tell and I’m sure there will be some novel implementations using this module popping up soon.
A definite plus point for the ESP12E though, is that the flash chip appears to be (a lot!) bigger. Here’s a post from Koelie2 on the ESP8266 forum with his findings after removing the RF shielding from an ESP12E module.
UPDATE: Link to Eagle library file temporarily removed — I just discovered an updated layout diagram on AI-Thinker’s shop page which shows that the new pins are not symmetrical about the centre-point after all. The link will go live again once I’ve had time to update the library file. [
In the meantime, here’s an Eagle library file for the new ESP12E version. Note that this is untested and the pads for the new pins were placed with the assumptions that they are symmetrical about the centre point of the module and that they share the same spacing and dimensions as the existing pads. ] Please let me know in the comments section if you spot any (other) obvious errors.
It’s also worth noting that the silk-screen on the new ESP12E modules shown on the supplier’s site (see Pete Scargill’s original post for the links) show the original, incorrect labels for GPIO4 and GPIO5. According to the board overlay on the same page, those silk-screen labels on the physical board are reversed. The Eagle library file (above) has this corrected (that is, the library file matches the board overlay diagram, not the silk-screen).
There also seem to be at least two, conflicting versions of what the new pinout assignments actually are (one layout on the Aliexpress site and another on the AI-Thinker shop page on Taobao). Given that the units all have “AI-Thinker” as the maker’s name engraved on the RF shielding plate, I’m going to use the Taobao version of the pin assignments for now. Hey, it’s good to see that we have such a track record of consistency with all things ESP8266… the documentation is consistently fubar-ed.
Espressif seem to take a minimalistic approach to publishing new versions of their SDK …if you’ve seen stuff before in a previous version of the SDK, you may not get it (even though you still need it) in the latest version that they publish. This usually manifests itself as complaints from the compiler such as “
stdio.h not found“, or a linker error “
Cannot find -lhal“. My fix for this is particularly inelegant and clunky; I simply copied the missing includes from an old version of the SDK into a directory called “extra_includes” and likewise with the library files, a directory named “extra_libs” and I modify the Makefile of every project I git-clone to include those extra directories as required.
The obvious issue with this is that every project needs to be modified not only when cloning, but on any subsequent git-pull where the source Makefile has been updated by the author. A simpler fix would be to check the contents of each new revision of the SDK and link in the missing components from the existing “extra” directories (linking rather than copying so that it’s easy to identify those files and remove them, if necessary, at some later date and also because linking has the beneficial property of not overwriting a file if it already exists). What I should do is bang together a shell script to make linking into a new version of the SDK a semi-automatic process (but, as one of my current ESP8266 heroes, Sprite_tm, is fond of saying in his comments,
/* I can't be arsed. */).
Martin Harizanov, who’s work I mentioned in a previous blog, has a slightly different method for the includes. He ships an extra include file,
include/espmissingincludes.h, with his projects, which has all of the missing function prototypes defined in it.
Of course, the best method to resolve the issue would be for Espressif to ship the whole SDK as a complete revision instead of in dribs-and-drabs.
Anyone who’s ever done a web search for “esp8266” will have come across some of Martin Harizanov’s work at some point. Martin has been playing with these modules since they first became available and, importantly, publishing his experiences as he went along. His blog, Martin’s corner on the web, is one of those sites worth checking out on a regular basis, to see what he’s come up with recently. A couple of months ago, he started teasing us with the promise of a mains power control board based on the ESP8266 and had the first prototypes (including schematics and board design) on the web, but no code. In replies to comments, Martin admitted that things were taking a wee bit longer than expected, but a few days ago he finally made his code available on GiHub. And it was worth the wait.
For those of us who learn best by picking apart example code, rather than reading the SDK manual pages (cough! If there are any. cough!), Martin’s work is the go-to reference. He’s managed to shoehorn so much stuff into there that there’s pretty much something for everybody to learn from. It’s true that he has taken a whole bunch of code written by others (Sprite_tm and TuanPM both get honourable mentions here) to create his baby, but basically that’s pretty much what we all do with Open Source projects; we take existing code as a starting point or inspiration and develop from it (Martin has a list of attributions on his Three Channel WiFi Relay Board page). What he has created is basically a complete product, both hardware and software, which has a web enabled front end where you can not only switch the state of the power relays or read the values from sensors, but also configure the network settings of the ESP8266 itself (for instance, changing the IP allocation from DHCP to a static address, changing the netmask and configuring a gateway) and then, still from the web, reboot the ESP8266 to have the changes take effect. The web stuff is all built on top of Sprite_tm’s ESP8266_httpd server. Then there’s the MQTT implementation from TuanPM, which allows the unit to communicate seamlessly with a server running an MQTT broker service. There’s an sntp service in there too, so your timestamps should always be accurate, a JSON parser so you can pass complex messages to your unit and have it decode and select specific data, a ThingSpeak interface and a weekly scheduler for heating control. There’s probably a ton of other stuff in there that I’ve forgotten to mention (or haven’t discovered yet), so you should wander over to Martin’s GitHub repository and clone yourself a copy to explore at your leisure.
Along the same lines, the current go-to blog for real world (ie:- “this doesn’t work, what am I doing wrong?”) ESP8266 development is Pete Scargill’s tech blog. I can identify with Pete; we’re both “mature” (read: “past sell-by date”), we both have a background which includes electronics and PIC micros, we both roll our Rrrrrrrr’s and we’re both struggling with the ESP8266. The main difference is that Pete is succeeding in his struggles, while I’m still flailing around in a fog. Pete’s blog attracts a lot of visitors (it’s well written, witty and informative) and each post generally generates quite a few comments, which are usually just as informative as the blog itself. Pete publishes titbits of code, pin-outs for new modules, tips on installing support software and tons of other stuff as he discovers it, so his blog is one of those daily-reads which you really shouldn’t miss if you’re working with the ESP8266. Recently he’s been working on getting the WS2812B series of controllable LEDs to work reliably when driven directly from the ESP module itself (no Arduino or other microcontroller involved), so if you’re into blinkenlights, pop over and take a look at his “ESP8266 WS2812B LEDs on a Plate” article.