ESP32 Hands-On: Awesome Promise

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

dscf8807_croppedWhat 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.

esp32_muxThe 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.

esp32_blockOn 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

dscf8826While 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.

esp32_techThe 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.

pinout_wroom_pinoutRight 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.

167 thoughts on “ESP32 Hands-On: Awesome Promise

    1. We evaluated the esp8266, and I blocked their use in products until Espressif comes up with:
      1. a reliable RC based WDT on die to deal with XTAL lock-ups
      2. a solid boot mode configuration that doesn’t randomly fail 10% of the time (we tried the dozens of solutions out there)
      3. when (not if) a chip does crash hard during initialization, the reset input can actually reset the entire die
      (a 15c part could have fixed 1&2 if this bug was not the case. )

      We will look at the ESP32 again, as I like the modules for hobby projects. The open RTOS and Arduino standardized platforms show a lot of promise, but there is no way I will allow them into a production product run until the reliability errata are proven to have a documented fix.

      1. That’s weird. I mean, the cheapest modules you can get – they couldn’t be simpler, yet they work. If it were a substantial problem, we would have known about it, because most of the problems similar to this are encountered by noobs who don’t wire them correctly or have a flaky power supply. Other than that, the ESP is quite robust, the only other noob trap being tripping the soft WDT by careless coding. Hell, I use 2 buttons for reset and boot mode and never had an issue.

        1. We tested across ESP01/ESP12E module versions, bias values, and test code.
          Current test rig for the 12E module (will test another 12F source again soon):
          RST pull up 10k, and GPIO16 deep sleep wake signal out
          GPIO15 pull down 10k
          GPIO0/2 pull up 10k

          We did not re-flow these, but carefully hand soldered them into a breakout board.

          Lock-up occasionally occurs during power connection to 3.3v 1A precision LDO supply (this is not some cheap 1117-3.3 brown-out issue). Our other test rig uses a 3A LDO with the same results…
          i.e. no stack dump, initialization status from TX line, or program mode switch on reset.
          A true power cycle in necessary to return cpu to run state, as the RST will not exit this failure mode.

          I suspect it is the very old XTAL start lock up issue many other manufacturers solved years ago. As once the device is running, than it seems fine. Perhaps the different module source will be more reliable, but so far its a no-go for board production.

          Btw, the user space software WDT task the current SDK API offers is kind of a ridiculous feature that misses the point entirely.

          Which module source are you using?

      2. I agree that the esp8266 has design and reliability problems but don’t have the skills to determine why. I was using the Huzzah version on battery power and implemented deep sleep/wake to max battery. ALL of the devices I tried would eventually lockup. I chalk it up to cheap Chinese design/parts/manufacturing. I just moved on to the more reliable MKR1000 and all my problems disappeared. For the time I wasted on the esp286 I could have bought dozens of MKR1000s. I tossed all my stock of eps8266 so I wouldn’t be tempted to use them.

        1. Yeah, these china companies service so good when you want to buy. But when you have problems, they ignored you. But when you showed interest buying again, they service you nicely. But you when you bring up the old problem, they ignored you again. This is china way of business, dog eat dog business. I saw these with my own eyes from 10 years ago until today same problems.All level of people in china have the same attitudes and thinking.

    1. I wonder if it will be as available as the $5 RPi is/was. I never had any supply issues with the 8266 but that gained popularity slowly over a couple of years while now everyone knows this is coming and is ready to jump on it.

      On a side note, I’m honestly surprised and impressed with the price-point they’re hitting with this! I thought it would be around $15 for a module, not $6!

      1. This order will get delayed due to further improvement of the module as seller replied below,

        Jerry Hong
        2016-09-28 13:10:28
        In order to further improve the performance of the product experience
        The official in the software still need further improvement
        So this order may need to delay shipments of approximately 3 weeks
        Your order, we have to do first registration queuing arrangements
        We hope to get your understanding
        If you want a refund, the company will respond to your application

  1. I’m really excited about this; I completely missed the ESP8266 bandwagon but got orders in to Seeed for five of these units the day they became available. Unfortunately I missed the first batch so I probably won’t see boards until mid-October, but it’s better late than never!

    1. Mid-October should be just fine! You’ll be getting the boards just about when the Bluetooth support is coming online.

      Like I say in the article, the software is _being_ developed as we speak. It’s not clear whether it’s more frustrating to have boards in hand and be unable to use them fully yet, or to not have the HW. :)

    1. It will be gradually open sourced. This requires a lot of code cleanup and is a lower priority than delivering the sdk itself. But that’s something that is on the company’s (and my own) agenda.

  2. My questions would be power, but it sounds like you’re already on that. How low can it go when it comes to voltage? Will it run on a couple of AAs for an hour, a day, a week as a mostly idle sensor? Will it tolerate running on a Li-ion directly?

    1. We have it, and I think all you need is an external CAN transceiver. Unfortunately, it’s at the bottom of our list of peripherals to document and write drivers for, so it can take a while before you see information about it appearing. We have to set priorities, sorry for that.

  3. “But you’re not number-crunching on an IoT wireless chip, are you?”

    I beg to differ. For serious IoT wireless, you have to use serious data security. And for that, you need serious encryption/decryption routines. And for those, you do need serious number-crunching. :)

  4. Is there a DMA-engine capable of driving I2C or SPI or the likes? On the ESP8266 you get a 64-byte FIFO-buffer for SPI, for example, but that’s not quite the same thing, as you have to keep supplying data to it after every 64 bytes transferred. Being able to point to, say, a 16KB memory-block and telling the ESP32 to splash those bytes out in the background over SPI while your code is doing something else would be nice.

    1. (Crap, did report instead of reply first. Sorry mods.)
      The SPI-channels have DMA (3 DMA channels, dividable over 4 SPI buses). I’m unsure if the I2C has DMA, I don’t seem to remember it has, but it does have a buffer of a few bytes like SPI has.

      1. I think this is the first time a comment of mine gets reported! Shame on you ;D

        As for your reply: thanks for the information. A FIFO-buffer for I2C is still better than nothing and leaps and bounds better than the software-I2C on ESP8266, and it’s great that SPI has proper DMA. Also, as feedback to both you and Espressif: I am quite delighted to see one of the actual team replying here in proper English and discussing things with people; that’s the kind of attitude that’s going to yield you guys a lot of goodwill in the long run! It certainly is appreciated. :)

  5. This time there will be good datasheets ? Th SPI interface in the ESP8266 is barely used in any project, just because there is no documentation to be found. At least not to the level of detail compared to other MCU producers. Wanted to combine the ESP8266 with a DWM1000 local positioning. Abandoned because there is not enough documentation on the SPI interface to tweak it correctly.

      1. So, does this means that in the near future ESP8266 is being abandoned?
        No news on updating the existing documentation and publishing some whitepapers on its reliability, power consumption, etc.?

        Shall we stop designing products with ESP8266? What are Espressif’ E-of-Life (EOL) and End-of-Sale (EOS) policies for ESP8266?


          ESP8266EX and its family

          ESP8266®chipset, – 12 years from January 1st 2014
          ESP-WROOM-02® – 12 years from January 1st 2014
          ESP LAUNCHER – 12 years from January 1st 2014
          ESP8285 chipset – 10 years from January 1st 2016

          ESP8089 chipset and its family

          ESP8089 chipset – 12 years from Jan 1st 2014
          ESP8689 chipset- 12 years from Jan 1st 2016

          ESP32 chipset and its family

          ESP32 chipset- 12 years from Jan 1st 2016
          ESP-WROOM-32® – 12 years from Jan 1st 2016

          best wishes
          rudi ;-)

      1. Thanks for the invitation. But I don’t have a ESP32 and switched to STM32 for the above reasons of lacking documentation. I must say that the STM32 -SPI to DWM1000 went remarkably well compared to the trial and error battle on ESP8266. I will use probably an ESP8266 – STM32 combination for Wifi connectivity.

  6. You underestimate both the ESP8266 as well as the ESP32. You already could run the ESP8266 at 160MHz if you wanted, and the ESP32 can go to 240MHz on both cores. Aside from that, this is indeed the state of the art today. Be assured that in the next two weeks we’ll be working our proverbial arses off and more functionality, drivers, and maybe BT will be popping up in the ESP-IDF tree.

    1. Hiya Sprite!

      Thanks for popping in and answering all of these questions. It’s not all that often and the engineers working on the hardware feel comfortable (or are allowed by the company) to talk about what’s in the works, why design choices were made, etc. Very cool!

    1. We actually have an ULP, which is a small coprocessor that is just barely Turing-complete, so you can still do simple stuff like getting samples from the ADC without waking up the rest of the chip. If you need more power, you can also wake only one core and boot it off a bit of RTC RAM. Should give you easier programming with very quick boot times and still low power usage.

        1. According to the datasheet, it’s got a threshold trigger too — you can sleep and only wake up when a pin goes below/above a certain analog voltage. Sleep at night? Wake up when the solar battery is charged? Cool possibilities.

          I’ll absolutely do a writeup of the various sleep modes and etc when the time comes. :)

    1. Hehe, that header is probably misleading. Yes, we do have a RTC, but the header is also about a gazillion of other things. Because of legacy reasons, ‘RTC’ became the name for a clock and power domain; a clock is one of the many things that live there.

  7. Nooo…! Dangit, the ESP-32 still has the silly “storage temperature range” of -40 to +85 like the ESP8266. I’m thrilled that it’s a wireless device with an operating range down to -40 (as far as I can tell, none of the cheap ARM SBCs are rated below 0) but without an (unpowered) storage range below -40 they’re sadly unusable for what I was hoping for them. Sniff.

      1. Which bugs me a bit, because even though my situation is a bit unique (I get not everyone’s designs need to work in arctic/antarctic conditions), you can definitely imagine use-cases for microcontrollers in very cold conditions.

        Very hot conditions is different (lots of people make uCs that run up to +125 C) , but very cold is weird. You’ve got TI, who sells microcontrollers rated down to -55 pretty cheaply, and… no one else.

          1. There a lot of applications that needs to comply with the industrial temperature range of -40°C to +85°C to simply meet the required specification. Would be very great to have the ESP-32 comply with this.

            The external main oscillator probably need to be exchanged by a model more stable in function of the temperature.

      2. Paradoxically, you may find that microprocessors will run at super low temperatures, but may not be able to be run as fast… it kills the thermal noise, but it makes other parts superconducty then you get weird leakages…… or something goes so low resistance that the current it pulls fries something else.

        1. It’s actually usually either the internal oscillator, or an internal core voltage. Lots of microcontrollers have temperature sensors that they use to steer the oscillator to the corrrect value over temperature, and outside of that range, they might not start up because the timings are out of spec. For the core voltage, at lower temperatures the core voltage often turns on slower, and if it turns on too slow, an internal voltage supervisor might try to start the chip running before it actually can run.

          All of which you could mitigate externally if you knew what’s going on inside the microcontroller, but unless you’re working with a manufacturer (i.e. you’re building lots and lots) or you have lots of money/time/knowledge to test the crap out of things, it’s a heckuva lot easier to just stay within spec with a thermostat-controlled heater.

          Storage spec is a bigger problem, though, because you can’t mitigate it (you’re not on when you violate it). I honestly don’t understand storage temp ratings of -40, there are plenty of places on Earth that get down below that during the winter.

          1. Some suggestions. Store in a vacuum, power and comunicate wirelessly. Buy the chip and test/ modify for the conditions needed before putting into service (didn’t even gander at the price but it has to be way cheaper than microcontrollers from 10years ago). Use a deep sleep mode till a certain temp, then power a small heater circuit. Encase in alot of foam for r value, and wrap in aluminum foil 1/2 inch air gap from the surface of the foam for a radiant barrier. Works almost as good as a vacuum. Or combine all for way more time powered off.

          2. “Buy the chip and test/ modify for the conditions needed before putting into service”

            I really disagree with this thought. I don’t design the chips, and manufacturers barely talk to you regarding what needs to be tested on a chip to verify it outside of its nominal range. It’s not worth it unless you’ve got enough resources to do it right, which we don’t have. It’s safer just to design to spec.

            “Use a deep sleep mode till a certain temp, then power a small heater circuit.Use a deep sleep mode till a certain temp, then power a small heater circuit.”

            Yeah, a thermostat-controlled heater which prevents the chip from turning on at all. That’s the basic idea. But if you can’t meet storage, there’s nothing you can do.

          3. … As funny as that is, even that wouldn’t work – you can’t turn off a heater like that. What would be needed in a lot of cases (and in our case specifically) is something to keep the system warm when power’s not applied, and then to be turned off when power is applied. The system generates plenty of heat on its own when it’s running, and adding a large additional heat load all the time would make things too *hot*. It’s just a cold-start issue, which is why storage temp is the concern. It’s relatively easy for things to stay warm once they’re up and running.

  8. I believe they are 12b DACs, not 8b. The use case for them was AC mains current monitoring. One DAC processes current and the other processes voltage. Doing this requires 12b DACs. They should also have a PGA (programmable gain amplifiers) on the front of them. The PGA is needed to sense current from 10A down to 1mA. ESP32 should be capable of making a smart outlet with power monitoring by adding $0.25 power supply chip (like MP153), a five cent op amp (LM2906) and a relay. Total manufacturing cost for this is targeted at less than $5 making $10 retail possible.

    1. I think you are confused between DAC (digital to analogue converter) and ADC (analogue to digital converter). For monitoring an analogue parameter like current or voltage you will use the 12bit ADCs. The 10bit DACs can be used to provide a controlled voltage output that might be used for motor control or even audio output if they were fast enough!

      1. You’ll need more than just the JTAG interface for debugging. JTAG is for testing only and anything else is a bolted on kludge not covered by a standard. You’ll need both onchip support for some low level access to onchip register, break point, trace etc as well as the software on the outside that talks to it and support some level of gbd or source level debugging.

        1. These particular NodeMCU-style boards don’t have an on-board debugger (which is a shame, i know). But the chip itself has JTAG debug port, and an on-chip debug module in the CPU.
          You can use OpenOCD along with GDB to debug.
          Here is the openocd version which supports ESP32: (another awesome work by Sprite_tm).
          Here are the instructions for using OpenOCD straight in ESP-IDF docs directory:
          Here’s a screenshot made by Baoshi, he is debugging ESP32 in Eclipse:

          Although i must admit, there are still some rough edges in the OpenOCD port. But we are working on them, because debugging is something we use daily, so it has to be good.
          Speaking of debugging hardware, a dev board with an integrated JTAG debugger is in the works. But any board supported by openocd should work. Here is the one many of us are using:

          Another cool feature of the ESP32 is hardware trace module. It can record PC after every branch/conditional jump taken, into a block of memory which can be reserved via menuconfig. One can use openocd to download the trace and decode it, getting a nice view of program flow. And there is also performance counter module in the CPU… And a SystemView port i’m working on…

          1. And again something that the ESP8266 could do. The question is: how many hardware breakpoints? Having only one sucked, because its either break or single-step, not both.

    1. Yes, we have ported software AAC, MP3, FLAC and OGG decoders to stream audio from the network. You’ll get the best quality with an external I2S decoder, but I’ll see if I can come up with something to do delta-sigma on a pin, or maybe abuse the DACs we have.

      1. Ok wow, now I’m impressed. I’m really excited by the level of involvement you/Espressif have been showing with the ESP32 compared to the ESP8266 and I can’t wait to get involved and see how things progress. Thanks for keeping us in the loop, it goes a long way towards showing how much more seriously this release is being treated!

        1. What Tobias said, squared. I2S is, IMO, the right way to get audio data out to a DAC, and all the good DACs support it.

          Sprite_tm will play around with making a PWM demo just to please the minimalists, but to make it sound good, you’re going to want to take the easy way out and just use I2S and a good audio DAC for a few bucks. (Cough, Wolfson WM8524.)

          1. Depends what you want to do. If you just want a nice cheap music output then having this directly interface to a simple class D and a full range speaker (shock, mono) then it would be nice if it did it for minimal part count.
            The possibility of two way audio is interesting.

      2. So I won’t have to port your MP3 decoder project myself. Thats good news!
        I managed to squeeze in MQTT remote control on the ESP8266 version, guess that work was in vain… But at least I learned a lot.

    1. We have a mode where you can basically send WiFi management frames. Very quick to do because it doesn’t need association or a DHCP lease (or even an access point) and very fast and robust because it uses the WiFi encodings. It’s not compatible to the specific NRF24 protocol though, but the use case you would use it in is about the same.

        1. ESPNow does look interesting but it only supports unicast and < 20 devices from the documentation I have read.

          Would it be possible to use the Bluetooth interface to send/receive broadcast packets like you can on the NRF24 modules? This is something I do a lot to detect which devices that are near to each other and roughly how far(devices are worn by people so always moving). This would save me having to add a NRF24 module to the ESP32 modules like I currently do with my ESP8266 based projects.

          1. Thanks. No CRC in order to evaluate “myself” what data is plausible and what is not. The CRC calculation is not an issue, nor are the CRC bytes in the packet. But I like the packets with mismatched CRC to be accepted by the RF stack so that my functions can process those packets as well.

    1. It probably can’t without additional external SPI SRAM…
      ESP32 has 520 KiB SRAM.
      A stripped linux kernel is about 600kB, and 4MB+ is recommended.

      However, porting LiteBSD may be possible…

      I’m not trolling you… or am I?
      Imagine a Beowulf cluster of these… ;-)

    2. DSLinux, for the Nintendo DS is based on uCLinux, and is for ARM architecture, so that might be a good place to start. Though the DS has 4MB to play with so maybe some hack and slash needed.

  9. my biggest problem with this chip :-) is that I can’t buy one on a board yet.. :-( I really like the “brand-spanking-new mini development board” above but would like it much more if I could buy one! (or 10..). Sprite_tm, is there any chance you can tell us roughly when they will be available to purchase??

  10. One thing neither the Datasheet nor the Technical Ref Manual details is the capabilities of the CPUs. There is a lot of information on peripherals but according to the Xtensa LX6 information I can find there are a great many options that may be configured when you license the IP. These include:
    1. Hardware MAC (16/32 bit)
    2. Hardware Floating Point (single / double precision)
    3. Interleaved (3-way, 64-bit) VLIW instructions
    4. 32-bit GPIO and FIFO-like queue interfaces
    5. DSP Engines (ConnX D2, Vectra, VMB [baseband], Audio / Voice, IVP-EP SIMD Imaging / Video)

    Which, if any of these optional IP elements are available on this device?

    1. Good point, i think we should add a section in the reference manual on that topic. Still, you can check the list of options in the configuration overlay. Here’s the relevant header file:
      Windowed ABI, single precision FPU, zero-overhead loop option, MUL16, MUL32, MAC16, DIV32 to name a few.
      Releasing processor documentation from Cadence is in the list of things we are going to do, sadly we are not there yet.

    2. From memory, we have hardware MAC and a single-precision floating point unit. Iirc, VLIW and double-precision needs a 64-bit datapath, something that at that point wasn’t feasible to switch to. We don’t use the specific GPIO and queue interfaces; we have a more general ‘fast’ path to connect peripherals to. Sorry, no specific DSP extensions other than hardware MAC.

      1. No need to apologise, hardware MAC and SPFP are probably sufficient for most light-duty “number crunching” workloads, given that the wireless crypto is offloaded to a peripheral anyway.
        Tbh most of those DSP cores are targeted at LTE baseband processors (mobes, dongles etc) and are not necessary for this device.
        Sounds like a sensible tradeoff between IP cost, silicon area, power consumption and capability to me.

  11. I’ve never done internet-connected projects before, but this little board is so inexpensive that I’d like to try! Does anyone know if there are libraries available to connect to WPA-protected access points?

    Also, how hard would it be to program the ESP32 to connect to an access point, periodically retrieve a web page, and parse it? Afternoon project? Week-long? PhD thesis?

        1. Well, you’d probably get your hands on an ESP8266 + external DAC faster than on an ESP32. Of course, if having to wait a few weeks longer isn’t an issue then I would totally understand you going with the ESP32 :)

    1. ESP8266 can do that too. And you can program it in microPython, which AFAIK includes library for webpage parsing. But it might be limited by the size of page and amount of parsing you want to do. You can do this in C++ using Arduino-styled iDE.
      Also ESP8266 can cnnect to WPA access points, it can even be one. ESP-32 will have he same capability, because making a IoT chip that can’t use WPA or WPA2 would be just silly and stupid…

        1. What is this “garbage collection” of which you speak? :) :) :) We embedded systems programmers use dedicated resource pools, assuming we even need to dynamically allocate anything at all.

      1. I wanted to keep an even number of header pins, since the ESP3212 has 31 pins. All three ground pads are connected by the breakout board, so I didn’t think it was necessary to break out all three ground pads.

    1. A question:

      The article mentions that Sprite_tm works for Espressif, but what about igrr? His comments here seem to indicate some kind of close relationship with Espressif as well.

      igrr, Sprite_tm: Care to comment?

  12. So, does this means that in the near future ESP8266 is being abandoned?
    No news on updating the existing documentation and publishing some whitepapers on its reliability, power consumption, etc.?

    Shall we stop designing products with ESP8266? What are Espressif’ End-of-Life (EOL) and End-of-Sale (EOS) policies for ESP8266?

  13. How would this compare to a Particle Photon ($19 or even $10 for just the module) that has WiFi, Arduino, and cloud integration? I understand the excitement on the esp32, because of the possibilities, but there are other options around that one could pick up right now and are able to do the same IOT promise.

    1. Particle Photon is a module. The ESP32 is a chip.

      For a hobbyist, an ESP32 would also be packaged as a module of some sort. A commercial developer, however, would design a custom board and put an ESP32 directly on it. The BOM cost is worlds apart in that case.

      1. Another important distinction there is that a hobbyist (or a small business fabricating a hundred boards here or there) can’t just go and order, e.g. Broadcom BCM43362 chips used in the Photon. You’re basically forced to purchase that kind of middle-man module, whereas Espressif (or TI) will make relatively small-scale silicon distribution available to anyone who wants it – along with pre-made modules and development tools of course.

  14. What about the hall sensor?
    It’s shown in every feature list, but so far I haven’t seen any further description of it.
    Is it just a simple sensor, or can it measure angles?
    What is it’s measurement range?
    Can I just use a simple magnet to use an ESP32 module as a door/window sensor?
    Is it fast enough for RPM measurements?

    And an additional question about EPS-Now:
    Is this just a point to point connection, or can it also be used to make mesh networks, like, say Z-Wave?

    1. > And an additional question about EPS-Now:
      > Is this just a point to point connection, or can it also be used to make mesh networks, like, say Z-Wave?


      Or how about an article about the details of ESP-Now (ACK/No ACK, CRC/No CRC, Multipoint/Single-Point, tests)

  15. In order for the ESP32 to succeed it must be:
    – As open source as possible (hardware and software)
    – Have at least decent Arduino & MicroPython support. (Javascript & Lua support would also be nice)
    – ESP32 Dev boards must cost at most as much as a Pi Zero + sd card+ WiFi Dongle i.e. approx $15.

    It looks like the ESP32 will become all of these things eventually. So I’ll wait…..

    1. “As open source as possible (hardware and software)” — Um, everything aside from the WiFi/bluetooth-stuff is already that. Just go and grab their github-repo and hack away.

      “Have at least decent Arduino & MicroPython support.” — Seeing as how popular the ESP8266 Arduino-core is I would be quite amazed if ESP32 didn’t get at least as good an Arduino-core, too. No idea about MicroPython, tho.

      As for the last one: the modules are already $7 and they just launched. I’d be surprised if a Nodemcu-style board went as high as $15.

  16. “most mortals have been combining the ESP8266 with a second microprocessor for more peripheral choices.”

    Most mortal did that because most didn’t want to learn how-to flash yet another MCU, and then stuck with AT+ commands…

  17. Interesting advance beyond the first ESP release, thanks, few questions:-

    1. Can anyone report progress/discussion elsewhere re the clock issue raised by OLD_HACK ?
    2. Any detail on interprocessor communications re API’s etc ?
    3. Given spi flash off one cpu can the other core’s leads affix to a 2nd spi flash,
    4. Updates on availability ?

    Looking forward to any pertinent replies or just observations, thank you

    1. 2. You have APIs offered by FreeRTOS: queues, queue sets, semaphores, task notifications, event groups. There is also an “inter processor call” API which allows you to run some code on the other CPU at high priority, see

      3. SPI flash is attached to SPI interface, not to the CPU directly. You can attach another flash chip to a different SPI interface (sharing pins and having two CS lines is also possible). Then you can use SPI registers to talk to the other flash chip (once documentation is released, that is).
      For now, spi_flash_read/write/erase APIs can only work with the “main” flash chip, but we do have a plan to support other flash chips with the same APIs.
      Code execution and encryption only works with the main flash chip.

  18. Hi…I am concerned about reliability of ESP32 in commercial product. I want to know, is it advisable to use ESP32 in commercial product, or I should go for already developed and stable hardware for IoT based development ?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.