The ESP32 is looking like an amazing chip, not the least for its price point. It combines WiFi and Bluetooth wireless capabilities with two CPU cores and a decent hardware peripheral set. There were modules in the wild for just under seven US dollars before they sold out, and they’re not going to get more expensive over time. Given the crazy success that Espressif had with the ESP8266, expectations are high.
And although they were just formally released ten days ago, we’ve had a couple in our hands for just about that long. It’s good to know hackers in high places — Hackaday Superfriend [Sprite_tm] works at Espressif and managed to get us a few modules, and has been great about answering our questions.
We’ve read all of the public documentation that’s out there, and spent a week writing our own “hello world” examples to confirm that things are working as they should, and root out the bugs wherever things aren’t. There’s a lot to love about these chips, but there are also many unknowns on the firmware front which is changing day-to-day. Read on for the full review.
The Hardware
What we received in the mail was two official ESP32 modules (WROOM-32) on a brand-spanking-new mini development board. (It was labelled August 31, 2016 by hand on a sticker on the back and we received it on September 4 in Germany, so you know it’s fresh!) The development board breaks out all the module’s pins to 0.1″ headers and provides a USB-TTL serial adapter, programming and reset buttons, and a power regulator to supply the ESP32 with the 3.3 V that it craves. It’s just enough to easily test out the ESP32, but not much more.
The ESP8266 started a small revolution by bringing WiFi to a small and cheap package that also had enough processing power and enough pins to get small things done. The price point came with limitations: insufficient processing power for fast WiFi, or for doing CPU-intensive activities while using the WiFi, too few GPIOs, one ADC pin, and no on-board USB. Of course, if you give hackers a set of apparent limitations, they delight in nothing more than breaking them. So we’ve seen bit-banged Ethernet and USB, the ESP8266 used as a WiFi motor controller, and more. But that doesn’t make the limitations any less real, and most mortals have been combining the ESP8266 with a second microprocessor for more peripheral choices.
The ESP32 addresses most of these deficits, except the USB. We’re guessing that they had to draw a line in the silicon somewhere, and since this chip is all about wireless connectivity, USB didn’t make the cut. Oddly enough, the datasheet also lists an Ethernet MAC, which belies our wireless hypothesis. Bah!
Two CPUs, Both Fast
Espressif doubled-down on the CPU resources for the ESP32. If you were complaining that you couldn’t do enough number-crunching on the old ESP8266, you’ll be able to do approximately four times as much with the ESP32 — both CPUs run at 160 MHz instead of the ESP8266’s (stock) 80 MHz.
But you’re not number-crunching on an IoT wireless chip, are you? The second core is simply there to make your life easier. For instance, the obvious division of labor would be to dedicate one core to real-time hardware tasks like graphics or motor control, while the other core handles communication. That way, you don’t have to think hard about weaving through the timings. But we’ll talk more about the dual cores below in the RTOS section below.
Peripheral Madness
Where the ESP8266 was great at providing WiFi on the cheap, the ESP32 seems like it’s trying to become the only microcontroller you’ll need for your IoT device. And that means more peripherals, GPIOs, and hardware-level creature comforts.
The I/O section is noteworthy. Working our way from the physical pin inward, there’s a multiplexer that allows multiple functions to share the pin. One of the routing choices may lead to an analog subsection, for instance. Some pins have dedicated hardware peripherals at the I/O MUX stage. The coolest option, though, is “GPIO” which then leads to a matrix that connects any of the digital hardware peripherals to that pin. Want UART2 RX on pin 13? No problem, just set it up in code. This should go a long way to help ease routing and pin-contention conflicts among the peripherals.
And there are a ton of hardware peripherals, some with interesting quirks. The PWM unit, for instance, lets you specify fades between different duty cycles, and everything is taken care of in hardware. There is an infrared I/O peripheral that does the work of encoding and decoding modulated IR signals. Between these two, there’s tremendous potential for strange waveform generation here. Mark my words — these will be abused for great fun.
On the analog side, there are two 8-bit DACs, and two 12-bit ADCs that multiplex over eighteen pins. There’s a built-in analog preamplifier, a temperature sensor, and even a Hall sensor. The analog section on the ESP32 is a far cry from the ESP8266’s single ADC input pin.
There are three UARTs, three SPIs, two I2Ss, and two I2C busses. All of these participate in the I/O matrix, so they can be routed to any pins, but they are also able to run at higher speeds when associated directly with certain pins through the first-stage I/O MUX. This looks like an interesting compromise between physical reality and total flexibility. Playing around with the routing possibilities and testing the speeds of these communication peripherals is on our to-do list.
Finally, to support WiFi and encryption, there’s now dedicated AES and SHA peripherals onboard, so you can encrypt and hash quickly without paying a CPU penalty.
If you want to know any more about the hardware, you can read all about it in the datasheet and the technical manual (PDFs).
The Software
While the hardware is now a done deal and the silicon die is cast, the software side of the project is very much still a work in progress. Indeed, we haven’t geeked out on the built-in dual 8-bit DAC peripheral yet precisely because we don’t have a memory map or any of the header files that would let us use them. But we know that they’re there, because we can see them in a string dump of the binary libraries. We just can’t get at them yet.
Espressif is taking a bold step here and developing a lot of the software side of the platform in public. The new ESP32 SDK, referred to as the “IoT Development Framework” (IDF) to keep it separate from previous SDKs, is being developed in public, even as we type, on GitHub. In the week that we’ve been using it, there have been something like 70 commits, some of them solving problems that we were actually having with the chip.
What this means for the end user is that the IDF is somewhat of a moving target. They haven’t pushed code that broke any of my demonstration programs yet, but [Sprite_tm] warned me that they might in the next couple of weeks. On the other hand, it also means that we’ll get access to the IDF code just as soon as it is available, and won’t have to wait for the entire suite to be ready if we were only interested in parts of it.
RTOS SDK versus the IDF
The ESP31, the development version of the ESP32, had its own firmware development repository: ESP31_RTOS_SDK. It’s essentially a port of the RTOS version of the ESP8266 to the new chip. As such, during the porting work, the Espressif coders got to learn a lot about the new hardware and how the old software architecture plays out on it. Although you might be fooled by the availability of “RTOS 3.0” for the ESP32 on Espressif’s website, it points to the ESP31 SDK which is going the way of the dodo, while the IDF is the new hotness.
The biggest difference between the ESP31 and ESP32 RTOS libraries is in the way that the two CPU cores are treated by default. In the ESP31 libs, one core is dedicated to “user applications” while the other is dedicated to communications protocols. This is brute-force, asymmetric multiprocessing with each core having dedicated tasks. True symmetric multiprocessing is more flexible, with tasks switching to the CPU that’s free at the moment, and this is where the IDF shines. Symmetric multitasking makes better use of the dual cores for most applications. The cost? A huge code rework to make sure that tasks switch correctly between cores and everything plays nicely together.
Combining open development with a fundamental architecture change means that significant functionalities of the chip, at least as far as the nuts and bolts of programming is concerned, are in flux. For instance, just a week ago you couldn’t run WiFi and be using the two cores symmetrically — a legacy of the previous asymmetric strategy — but now you can.
The Espressif team is also taking the opportunity to revamp their function-naming conventions. On the one hand, they’re rationalizing a lot that had developed piecemeal over time. On the other hand, the function that you used to know as wifi_set_opmode() is now called esp_wifi_set_mode(). Porting ESP8266 code to the ESP32 won’t be impossible, because the operational logic is very similar, but the name changes will make it awkward at first. (Perhaps a concordance and a simple translator script would take care of most of this?)
What’s Working?
To get a reasonable overview of the current status, have a look at the header files in the components/esp32/include directory. The GPIO and function matrix is fully functional and we’ve actually tested it out. There’s headers for the real-time clock, AES, SHA, buffered UART, and register definitions for SPI and I2S. There’s JSON code, a port of mbed’s TLS module, the lwIP lightweight IP stack, and more in the software stack. Notably lacking from this list (at time of writing) is the Bluetooth stack and a lot of the oddball peripheral drivers.
The Verdict: An ESP8266 Killer? Not Yet.
Right now, if we had a project that needed WiFi connectivity and we wanted to get it done quickly, we’d still pull an ESP8266 out of the drawer. The ESP32 IDF is still too rough around the edges to get a project together fast. On the other hand, we’re more than excited to have a couple to play around with, not least because we simply like poking around in the memory maps of sexy new chips and seeing what they can do. And we all know what’s going to happen — in a few months the chip will have had the full Arduino and/or NodeMCU treatment and even noobs will be writing WiFi and Bluetooth applications with this part. (We can’t wait!)
Combining lots of physical I/O and a broad range of hardware peripherals with wireless is awesome. Every project we see with an ESP8266 tied to another microcontroller chip is a testament to this fact. The Arduino Uno WiFi and the Arduino/Genuino MKR1000 boards have also tried to capitalize on this niche by tacking a microcontroller onto a WiFi module. If the ESP32 is going to be able to stand on its own, provide the wireless connections we crave, and do so for very little money while being widely supported by easy-to-use community libraries, it’s going to sell like wildfire.
What’s Next?
So we’ve got two of these in our hands, an inside man at Espressif, and we’ve just scratched the surface. Next, we’ll have a look at the real-world power draw, which will mean cutting some traces and soldering some green wires. After that, we’ll probably tackle multiprocessor coding, or look into the TLS capabilities or the Bluetooth stack when it comes out. What burning questions do you have about the ESP32? Let us know in the comments and we’ll do our best to get you answers.
Read more: ESP32 Hands-On: Awesome Promise
