ESP32 Breakout Board

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.

HydraESP32 breakout board, by "HydraBus"

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?


ESP32 Module!!

This picture of the WROOM-32 module pinouts has been produced by Alberto Piganti (PighiXXX).  I would have dismissed it as an April Fools Day joke, especially given the strange capacitor layout around the antenna area …but it’s August and, more importantly, the 

WROOM-32 Module
Courtesy of Alberto Piganti

information was re-tweeted by John Lee, of Espressif.   Also, the datasheet for the module appears to be available.

I really don’t know whether this is a mock-up, prototype, or just a rendering based on the pin-outs and top-view outline available in the datasheet (although it is most likely the latter) and right at this moment I don’t have the time to be able to follow-up.  So if any of you interested readers out there would like to do some sleuthing, please carry on and let us know what you find out in the comments section.

The picture link will load the original, full-size PDF file, BTW (just in case you’re allergic to PDFs).


PlatformIO, the ESP8266 and an ancient Linux version

A couple of the sites which I list in the links section (see the menu to the right) have been singing the praises of PlatformIO in connection with ESP8266 development recently.   Squix actually goes as far as propose using PlatformIO as part of a “Continuous Delivery” workflow for the ESP8266 (no, I didn’t know what it was either, but apparently it entails adding automatic testing to verify that a given release meets certain criteria before being released to the target device), while Jan Penninkhof was so impressed with PlatformIO that he put together a very nice “How To” video on getting started with it on the Mac.

But hold on, just what is PlatformIO and why would I want it?  PlatformIO is a build system; it’s like “make” on steroids, as implemented by Superman, with help from Jethro Tull†.  If you want to build a project for the ESP8266, PlatformIO will help you to do it by (for instance) downloading the toolchain automatically for you.  If you decide you’d like to build for two disparate architectures (lets say ESP8266 and TeensyLC) you can just let PlatformIO know that at initialization time and it will magically download and install both toolchains and support when you first attempt to build the project.  If you include libraries (via the normal “#include <whatever.h>” method) in your code, PlatformIO will help you find the latest version and automatically download any dependencies which your chosen library may have.  Basically, if you’re a newcomer to the ESP8266 world, this is the easiest way to get started compiling and flashing.  Don’t bother trying to follow the (mostly conflicting) instructions on the 50 odd (out-of-date) web sites on how to install the toolchain, or how to configure esptool for flashing, or how to set-up the Arduino-ESP environment… just install PlatformIO and let it do it all for you.

All in all, it looked like something worth trying to me, especially after Squix and Jan had explained some of the features in plain language (which is wonderful, because  buzzword-laden sentences containing “framework”, “integration”, “extensible” and friends put my brain into deep-freeze mode).  My main issue with anything “new” like this though, is usually my ageing primary work machine.  I’m running a fairly ancient version of Elementary OS, which is based on Ubunt 12.04.  Attempting to install anything written after the Magna Carta on this steady old workhorse usually results in a raspberry from the speaker as well as the normal, copious error messages about the kernel, libraries, disk spindle bearing and user all being past their “sell by” date.  I’ve given up even trying to install anything which mentions “Java” anywhere in the description.  PlatformIO though, is written in Python and although I’m not a Python programmer, I do know that the version installed on my system is quite a recent one, as the ESP8266 loader program required it.  A quick check with “python –version” showed that it was actually 2.7.3.  Almost all versions of Linux have some type of updater attached to the package-manager,  so you should be able to update your system (no matter how ancient) to a recent revision of Python without too much effort.

Moving on to getting PlatformIO working, the next step is even easier.  We now need to use the Python package installer, “pip”,  to do the grunt work of adding PlatformIO itself.  You can check to see whether “pip” is already available on your machine using a command such as “which pip” or “whereis pip“.  If “pip” exists, they should return the fully-qualified location; something like “/usr/bin/pip“.  If it doesn’t exist, you’ll need to use the system package-manager to add it (which might be as simple as “sudo apt-get install pip“) to install it.  Assuming that “pip” is now available to you, simply do:-

pip install -U platformio

Note that the “-U” option comes after the “install” command.  It forces pip to update the install target to the latest available version.   And that, basically, is that!  You now have platformIO installed on your ancient Linux system and it’s going to do all of the rest of the heavy lifting for you.

Now that you have it installed, you can create a work directory for your projects.  I just made a PlatformIO directory directly under my home directory as an easy way to get started, but basically you can call it whatever you like (“work”, “projects”, “Eric-woz-ere” will all work equally well).  What we’re going to do now is to create sub-directories in the work directory for each different project that you build.  This is good practice anyway, but PlatformIO makes it almost essential, as it supports a metric ton of embedded processors (as well as their different toolchains), so one project might be built for the ESP8266, while the next might be for the STM32-Discovery and the one after that for the TI MPS430.  PlatformIO will quite happily build each of your projects for a different processor (or even for multiple, different processors) if you want it to.

Okay, so to start off, we’re going to build a simple door-bell project for the ESP8266.  Basically, this is going to be a battery powered project and, because it’s housed inside an enclosure attached to a wall, we want to enable OTA programming to allow us to update it without ripping the enclosure apart each time.  We have some basic code already available which has been developed (to date) in the Arduino-ESP environment.  Lets start…

mkdir DoorBell  && cd DoorBell

mkdir ./src

cp ~/Arduino/DoorBell/DoorBell.ino ./src

cp ~/Arduino/DoorBell/user_config.h ./src

So, we’ve created the “DoorBell” sub-directory, changed into it and created a “src” directory, then copied over our code (and an include file) from the existing Arduino build tree into the new “src” directory.  Now we need to tell PlatformIO which target processor we want to build this project for.  You can get a (very long) list of the available targets using the “platformio boards” command.  You’ll need to scroll up through the output to find the  “Espressif” section.  Most of the common ESP boards are in the target listing, including things like the Huzzah and NodeMCUv2; there are also some that I’d never heard of, such as the Phoenix and WifInfo (which seems to be this).  I’m actually using the “esp12e” setting for my project (even though it’s just a generic ESP12 processor), with no ill effects.  To implement your board choice and have platformio write it’s own, minimal configuration file for this new project, use the “platformio  init  --board=phoenix_v2” command (which, in this example, is setting the board type to “Phoenix V2” …replace this with your own choice).

The init command (above) will create a bunch of files and directories under your newly created project directory.  The main ones are:-

  • platformio.ini      – The configuration  file for this project instance.
  • src      – The directory where PlatformIO looks for the source code for this project.
  • lib      – The directory where PlatformIO will look for custom, local libraries which you might add.

We already created the “src” directory in our initial steps, above; that’s okay though, the “init” command will not overwrite an existing directory.  The other contents of this newly initialized project directory can change, depending upon (for instance) which IDE you choose to use.  As an example, if we tell PlatformIO that we want to use the “Eclipse” IDE, using “platformio  init  --board=phoenix_v2 --ide=eclipse“, we will end up with an extra “.settings” directory and “.project” file, both of which contain template information specific to the Eclipse IDE.

The platformio.ini file is fairly sparse at initialization time, but it is important.  For instance, the default framework environment for the Espressif processor is “arduino”, but by editing your platformio.ini file you could change this to “simba” (that’s actually the only other valid framework available for Espressif targets).  If you now start a compile with “platformio run”, PlatformIO will immediately go off and automatically download and install the Simba framework package for you, before kicking off the build of your project with a totally different framework (if you try this, please be aware that not all of the Espressif boards are supported by Simba, whereas most of them seem to be fine with the default Arduino setting).

This semi-automatic mode of operation is an intrinsic part of PlatformIO and does make life easier for the novice user.  Another good example is when it comes to uploading your newly built code to the target board.  When we start off, we don’t generally have any other option than uploading via serial.  To kick-off the upload process, plug your ESP board into your computer, as normal and then use the command:-

platformio run -t upload

PlatformIO will go off and automatically detect your serial device (this works very well if you’ve already been using your system for programming an ESP board …if you’re starting from scratch in a clean environment, you might have to check the 99-platformio-udev.rules file settings – this is Linux-specific BTW), and  upload to the ESP.

That’s it.  You’ve just built and uploaded your project using PlatformIO.

Once your ESP board is up and running and connecting to the network, you can very easily change to using the Arduino-style OTA upload method by going back and editing the platformio.ini configuration file.  Just add the line:-


(where “” is replaced by the actual IP address of your ESP board) to have PlatformIO alter its behaviour to the “upload” command to use OTA instead of serial.  Of course, you need to add the Arduino OTA support code to your project file too, before this will work (see the example file BasicOTA.ino for the lines of code you need to add …the basic OTA functionality is already incorporated into the PlatformIO/Arduino libraries).

A word here on libraries.  Normally we use libraries created by others to add functionality to our projects.  A good example of this would be the PubSubClient library for MQTT.  As you might expect, PlatformIO provides a method for handling third-party libraries like this and, naturally enough, one of the first things a new user needs to do is find the libraries needed for a given project.  We can query PlatformIO for the MQTT libraries it knows about using:-

platformio lib search MQTT

This will return a numerically indexed list of libraries matching the keyword “MQTT”.  Currently this returns 13 hits on my system.  As it turns out, Nick O’Leary’s PubSubClient library is the first one in the list, with the reference number “89”.  Okay, lets get PlatformIO to download and install it:-

platformio lib install 89

Note that we use the reference number, not the name.  PlatformIO downloads and installs the library and adds it to it’s own database.  What’s nice about this is that it will check every week or so to see whether the library has been updated recently and prompt you to refresh your installation if it finds that you’re not running the latest revision.

As you might expect, PlatformIO also runs the “latest and greatest” revision check on itself and will also prompt you to upgrade if you’re not at the latest rev.

I’m impressed!  Since trying PlatformIO for the first time a couple of weeks back, I’ve been moving everything over to it.  No more messing around with the horridible Arduino IDE.  Yay!



† – The man, not the group.  Implying that it does some basic, but essential stuff for you, not that you’re as thick as a brick.


This bandwagon is starting to get pretty crowded…

With every passing week we get another ESP8266 “killer”, but usually not quite as cheap and almost always without the same software or toolchain support that we (now) have for the ESP.

Regular readers will know by now that I’m an old Unix guy and that I’m quite a fan of the new, low-power ARM boards which are popping up all over the place, although as with the ESP8266 killers, they tend to be short on the software and support side.  Recently though, I have been impressed by the folks over at FriendlyArm, who seem to put a lot more effort than most of their rivals into making sure that a board has an actual working OS (usually more than one) before it hits the marketplace (see “Headless Server Worth Having” from a couple of weeks back for some details on the very cheap NaniPi NEO).

Nano-Pi Neo board imageSo, it was with more than just a tiny spark of interest that I noted the latest rumour from that denizen of the Armbian development team, tkaiser.  He’d found a couple of references in some of FriendlyArm’s publicly available documentation referring to something dubbed the “NanoPi AIR”.  Apparently this will be the NEO, minus the ethernet, but with an AP6212 wireless/Bluetooth module instead.  Now remembering that the pricing for the NanoPi NEO starts at $7.99, we can safely assume that the AIR will be roughly in the same ball-park.  Price-wise that doesn’t make it an ESP8266 killer, especially as FriendlyArm add (a fairly reasonable) postage charge onto their orders, but it does make it a very, very interesting alternative.

Remember that we’re looking at a fully-fledged, multitasking system here, booting Linux from an SD card with 256MB (or optionally 512MB) of RAM and with all of the GPIO broken out to standard-sized headers (no castellated, sub-millimetre spaced weirdo connections).  The board is roughly half the size and one-third/half the cost (depending upon where in the world you are and how much postage you have to pay) of the Raspberry Pi.  You can write your code in C, Fortran, Lisp, Perl, Python, or just about any other language you want (Linux has ports of pretty much everything) and be reasonably certain that the drivers for whatever hardware interface you want to use will already be available to you and, while your IOT device isn’t fetching temperature readings (or whatever), it can also be serving NTP, DHCP and DNS traffic on your local  network and running an MQTT broker, all without breaking into a sweat.

As icing on this particular cake, one of tkaiser’s areas of interest with this specific ARM processor (the H3) is tuning the system for the lowest possible power dissipation by slowing down the processor clock during periods of inactivity.  The clock should go down to about 240MHz (from the max of 1.2GHz) and my recent experience with the NanoPi M1 (one of the NEO’s predecessors) is that it will very happily run at 480MHz with no obvious indication at all  to the user that anything has changed.  This means less heat dissipated and less power used, so although the NEO and AIR are unlikely to be useful as remote sensor nodes running on a couple of AA batteries, they would be useful in situations where a higher capacity battery was available (for instance, a multi-cell lead-acid unit on a solar charger).  For mains-powered projects they’re almost a no-brainer.

A couple of dampers on this; first, as I mentioned above, the AIR is just a rumour at the moment (it might be April the first on somebody’s calendar, somewhere).  The second thing is that the AP6212 is actually a pretty expensive part in small volumes, so I could be miles off in my parity-pricing estimate.  We’ll probably find out fairly soon.




Another ESP8266 “killer”

CNX-Software and Hackaday are both carrying articles on the Realtek RTL8710 today.  In case you haven’t already seen either of those (and I would recommend the CNX one for more technical details and buying info, if you’re so inclined), it’s basically an ESP clone (more castellated module pins at weird spacings) with an ARM Cortex M3, running at 166Mhz, with a little more available RAM than the ESP and 1MB of flash.

RTL8710 module layout

The modules have a metal can (similar to the ESP12) with an FCC logo, but Hackaday notes that they were unable to find any reference to it on the FCC site.

There doesn’t seem to be any useful information available for this module yet (apart from the price), so if you plonk down your cash, you’re going to have to do some guessing  about connections, pull-ups, pull-downs, pin max voltage handling, etc.  One seller’s site notes that deep-sleep for the unit is 10uA (so same ball-park as the ESP) and that the unit can respond to network traffic within 2ms of waking.   There is also mention of “IR Remote Control”, although what that actually means is anyone’s guess (there’s no obvious receiver on the module).  There are more available GPIOs (21 as opposed to 17 on the ESP).

So, right now I can’t see any reason for digging into my pocket for some spare change.  There are some attractive aspects to this new unit (more RAM and an ARM processor), but nothing that reaches out, grabs you by the throat and screams “Buy me now, or you’ll be sorry!”.  The main downer on the Realtek is that we’d all be stepping back in time by a couple of (fairly painful) years of trying to get a usable build environment working with little information available, other than Oogleg-translate versions of some Chinese forum postings (most of which condense down to “Honourable teacher, please be so kind as to tell us something, anything, about this wonderful plate”).  No, I don’t think I want to go back to that particular space-time continuum again in a hurry.



UI5 on an ESP8266

If you’re anything like me (poor eyesight and clueless), you might be wondering what the heck UI5 actually is (for as start, is that “Ewe-one-five”, “Ewe-Ell-five” or “Ewe-Ai-five”?).  Well, it turns out that it is shorthand for the “User Interface Development Toolkit for HTML5” (so “Ewe-Ai-five”) and here’s a “Give me the jargon-filled-buzzword-compliant-sales-hype” run down on what it is/does.

Jan Penninkhof's UI5 application

Jan Penninkhof has some neat ESP8266 projects over on his blog and he decided that UI5 was absolutely essential to his automated veranda control box (;TLDR version: He wanted to be able to configure newly installed ESP’s with their basic info and network settings from pretty much any HTML5-capable device).  The main problem being that a bare-bones UI5 build, without an application or any extra configuration files, weighs in at about 4MB.  Jan’s blog is a neat tale of how he sheared, pruned and trimmed down UI5 to be able to fit it into the ESP8266 available flash space and still do useful stuff with it.  Definitely worth a read!


Headless Server Worth Having

I use Unix™-like systems everywhere (I’m not going to get into a religious argument about this …I’ve been using various sorts of Unix for dang-near 40 years now and I just never quite got the hang of the GUI paradigm, so call me an old fart if you like; the moniker fits quite well🙂 ).  Recently I’ve replaced a few of the bigger, more power-hungry boxen around the house with ARM boards, which are inexpensive to buy and very cheap to run.  Some of the Linux offerings (Armbian, Debian, Ubuntu-core and the various siblings, family and friends) are doing an amazing job of keeping up with the ever-changing, disparate array of hardware coming out of the Middle Kingdom (and FreeBSD isn’t far behind), so using these tiny boards as headless servers is quite viable nowadays.

Recently I bought a Nano-Pi M1 (plus 3D printed case) from the FriendlyARM on-line shop, with the intention of pressing it into service as a 24×7 web-cam support machine and general anything-else-I-can-get-to-run-on-it server.  As an ESP8266 user, MQTT was one of the leading candidates in the “anything-else” category.  Well, the good news is that it’s really not that difficult to get a distribution to run on one of these $11 boards.  FriendlyARM do a lot better than some of the other manufacturers in making relatively up-to-date releases available from their web site and again, unlike some of the others, the choice of working distributions is actually greater than just one.

While I still haven’t got the web-cam up and running (anyone want to recommend a decent, cheap camera with reasonable resolution for landscape shots?), I have had a lot of fun playing about with this small board and trying out the various flavours of Linux available for it.

Having mentioned the Nano-Pi M1, I have to say that it is not the subject of this post, though.  While browsing my normal favourite collection of sites over breakfast this morning I came upon this little beauty (courtesy of CNX-Software …one of the better sites for cutting-edge info on embedded systems).Nano-Pi Neo board imageThis is the new, NanoPi NEO from FriendlyARM; the latest stable-mate to the NanoPi M1 (and for that reason, I have a quite reasonable expectation that this board will have good support from day-1 …and as my mouse hovers over the “Add to Cart” button, I hope that FriendlyARM won’t prove me wrong).

This tiny board (40mm x 40mm) has 100Mb ethernet, a USB-2 port (with two more ports available on header pins), a micro-USB socket for power and data, a Micro-SD card socket, a 36-pin header for GPIO (which includes I2C, UART, SPI and general I/O pins) all driven by a quad-core Cortex A7 running at 1.2GHz and 256MB of DDR3 RAM (512MB of RAM for an extra $2).

So how much is it?  $7.99 for the 256MB version.

Before I get screamed at, I need to qualify that price and tell you that the last time I bought anything  (the M1) from FriendlyARM, the postage was $10 (via DHL to most of the world,  so reasonably speedy), so you need to add that into your budget.  As far as I can see, there’s no case available yet (Update:- Just heard back from FriendlyARM that the case is in the works and should be available towards the end of this month …July 2016).

Update:-  It looks as though FriendlyARM have changed their shipping options.  When I went to “checkout” this time, the cheapest option was plain old “China Post”, with Fedex just a couple of dollars extra and the DHL/TNT option a few dollars more.

Update:- I mentioned in the original version of this post that it might be worth adding FriendlyARM’s $1 heat-sink to your order.  Better hold off on that for the time being.  The processor on the NEO is on the bottom of the board and we still have no  idea of what the case is going to look like.  Oops!

It’s going to be hard to beat this as an off-the-shelf, ethernet-connected, low power (as in watts used, not computing power) MQTT/DHCP/DNS server for your ESP8266 network.

Last word… for GUI-centric people, please do note that there is no video output connector on this board; it’s serial-console only.

Update (Aug 8th 2016):-  As of today, the printed case for the NEO is now  available for sale on the FriendlyArm site.  There’s also a fairly chunky heat-sink.  Both are priced at $2.99.  The pricing is a little bit of a downer, as together they bump up the total cost of the unit by a fairly hefty margin.  The other downer is the colour …do you really want a neon-pink case sitting anywhere around your house?


NanoPi NEO layout and specs