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.
As some people already know I made KiCAD footprints!
https://github.com/adamjvr/ESP32-kiCAD-Footprints
https://hackaday.io/project/13483-esp32-kicad-library
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.
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.
I never had problems with the module not booting or the reset not working. Maybe you can reset the module by asserting the CH_PD?
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?
Can you send me your contact info? Espressif factory would like to work with you on solving this issue.
jonsmirl@gmail.com
Did you report these issues and what did they say?
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.
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.
Hmm I2S on a WIFI IC… All for it!
Looking great Espressif!
The ESP8266 had that already. Heres sample code on how to use it: https://github.com/espressif/ESP8266_MP3_DECODER/
So when can we buy this development board? :)
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!
Burning question: Where can I get one? Neither ebay (in it’s .co.uk incarnation) nor aliexpress are showing up much.
I’ve had better luck using the keyword “ESP-32” instead of “ESP32”, but I agree, hard to find.
https://www.aliexpress.com/item/ESP32-WiFi-Bluetooth-module-Dual-core-CPU-Ethernet-port-MCU-Low-power-Bluetooth-ESP-3212/32731347417.html
Sheesh, that’s some expensive shipping.
I smell a group buy.
This same link shows up to me with free shipping to Brazil, $4.75 per unit
*orders 2 with china post – $13 well spent tbh*
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
respond does not mean will refund. they will just delay, ignore you.
There are some still available here: https://groupgets.com/campaigns/250-esp3212-wifi-bluetooth-combo-module
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!
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. :)
Too bad most of the RF software is still undisclosed, and I don’t trust what Espressif is trying to hide in there.
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.
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?
I’ll be whipping up a board that can do that relatively soon, once SunLeaf V2 is out. Fallow my profile https://hackaday.io/adamjvr
According to the datasheet linked in the article, it can be powered from 2.3-3.6 V, so no, it won’t tolerate running from a Li-ion cell (up to 4.2 V) directly.
Could do LiFePO4 though.
Which you can easily give a try with this:
https://hackaday.io/project/7312-lifepo4weredusb
I’m just an ignorant noob looking for enlightenment… Isnt USB 5V? I can’t see this working without blowing up the ESP32, so I must be missing something in my understanding.
@kramboz the board regulates the voltage down to a max of 3.6v
Hey come on Elliot, letting through only positive comments? How much does this company pay you for such a great marketing service you are providing?
Patience… moderating comments sometimes delays them from showing up publicly. This is a function of spam mitigation, not censorship.
How about CAN? Is already known whats needed to use it?
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.
Can you at least document what pins it is on? Concern here is that it will never arrive and I know of a few projects (mine included) waiting on this.
Any pins… It is on the matrix
> Any pins… It is on the matrix
Quick, somebody call Neo
“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. :)
Well, you do have hardware RSA, AES and SHA to help with that…
And ECC?
I have done a port of https://github.com/kmackay/micro-ecc for the ESP32, it uses BIGINT hardware module for modular multiplication (e.g. abuses RSA accelerator). So yes, you can do ECC. Although at 240 MHz, software ECC is also pretty speedy (“verify” operation on secp256_r1: 60ms). Probably even faster for, say, Curve25519.
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.
(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.
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. :)
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.
For sure. We’ll be writing register level documentation on all the public peripherals (=everything except low-level WiFi and BT). Check out the Technical Reference Manual on https://espressif.com/en/products/hardware/esp32/resources . As with the ESP-IDF, it’s still a work in progress, but this is the level of detail you can expect.
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?
http://espressif.com/en/products/longevity-commitment
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 ;-)
how old is espressif? :-)
I am also working on ESP32 connection to DWM1000. Care to collaborate?
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.
Hi,
I am looking at the same thing. Still open for collaboration?
Cheers
S
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.
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!
Shut up and take my money. I’ve been developing on ESP8266 dev boards for a few months and loving it ( https://hackaday.io/project/10463-beehive-monitoring-now-with-wifi ). I haven’t hit it’s limits yet but…
Deep Sleep mode like its older brother?
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.
This sounds like a killer feature if you ask me! I would love to read more about that one, preferably in article format instead of from the datasheet.
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. :)
Does it have it’s own real-time clock or is the header to accept input from an external RT
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.
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.
Well, it may be rated at it because here in tropical Shanghai no-one is aware that -40C is a real temperature, let alone that there can be temperatures lower than that.
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.
Poke me at jeroen at espressif period com, I’ll see if I can ask around for you why the -40C is the limit we have. Also, I’m interested in your use case, not many people who make arctic devices.
maybe he’s going up in altitude more so than to arctic climes?
Both, actually!
Sprite_tm, I’ll shoot you an email.
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.
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.
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.
https://en.wikipedia.org/wiki/Operating_temperature
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.
Space permitting of course
“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.
How long do your devices need to last? Assuming it’s no more than a decade or two, you can just pack your favorite radioisotopes around it to keep it cozy.
… 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.
can it boot from spi without removing the flash chip?
(http://hackaday.com/2015/12/09/raspberry-pi-wifi-through-sdio/)
Yes. It can do SDIO boot but you need to bootstrap pins accordingly. Alternatively you can program a few OTP bits to force SDIO boot.
Soooo looking forward to this. It would make the ESP32 a perfect companion to a Pi Zero. Any plans/timeframe for releasing suitable firmware (and maybe some driver code too)?
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.
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!
DAC = digital to analog output
You are talking about ADC for reading voltage.
mp153? do you have a DS. having a hard time finding it.
I wasn’t paying full attention when typing.
I meant ADC not DAC.
It is MP157
https://www.monolithicpower.com/DesktopModules/DocumentManage/API/Document/GetDocument?id=11
Can haz 12-bit hardware multipliers for power calculation?
Each CPU has 16-bit hardware multiplier. But at 240MHz even a software one would do.
Will it be compatible with the Arduino IDE?
Of course. There is an ESP31B port by me-no-dev, and he has just received his ESP32 boards. It won’t take him long to port to the ESP32.
This is what I am waiting on, I have already found some boards on Aliexpress. I am just holding off ordering incase some better boards appear before Arduino support is functional.
Still no JTAG debugging? Seems awfully primitive without a modern debugger.
Exactly. Without a proper hardware debugger, it is a toy – just like an Arduino
The board doesn’t have built in JTAG, but tdi,tdo,tms,tck pins are there
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.
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: https://github.com/espressif/openocd-esp32 (another awesome work by Sprite_tm).
Here are the instructions for using OpenOCD straight in ESP-IDF docs directory: https://github.com/espressif/esp-idf/blob/master/docs/openocd.rst.
Here’s a screenshot made by Baoshi, he is debugging ESP32 in Eclipse: https://twitter.com/ba0sh1/status/776214509434175488
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: http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
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…
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.
The cores in ESP32 have two breakpoints and two watchpoints. This is also mentioned in openocd tutorial linked above.
FWIW: I got OpenOCD working on the demo chips, using an FT2232-type adapter by following the instructions that [igrr] linked above. If I can do it, then so can you! :)
Also, with a bit of luck, if you do not use the trace memory, I can abuse the stop condition of that as a 3rd breakpoint. That’s a hack I want to do when the rush is over, though.
Can this module stream music from the internet or home network and play the music out on one of the pins?
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.
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!
Thank you for your response. I will want to be able to make a smart wifi/bluetooth speaker with the ESP32 at the heart of it. Are there any good I2S decoders out there?
there are lots.
For example these: http://www.audiophonics.fr/audiophonics-dac-sabre-es9023-i2s-vers-analogique-24bit192khz-p-8396.html
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.)
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.
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.
Whoa.
In terms of tech gadget obsession, I’m way more excited for the ESP32 than I’ll ever be with the new iPhone or Galaxy S7!
Bring it!
Does the ESP32 support a protocol similar to NRF24?
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.
Ah, the mode is called ESPNow, and the ESP8266 already has it in the SDK if you want to play with it.
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.
Thank you for your reply. ESPnow supports NO ACK and NO CRC?
“ESP8266 already has it in the SDK if you want to play with it.”
Don’t wanna play, wanna use. That’s why I asked.
If I recall correctly, it does support no ack. I don’t think the CRC is switch-off-able, but I’m unsure why you would want that switched off.
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.
Can it run Linux even if it is just uClinux?
The 520kB SRAM is certainly not enough to boot even a light Linux system. Someone added an SDRAM to an AVR to boot Linux on it: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit So this might be possible for the ESP32 as well but probably more a geek hack than a usable feature.
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… ;-)
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.
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??
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?
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:
https://github.com/espressif/esp-idf/blob/master/components/newlib/include/xtensa/config/core-isa.h
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.
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.
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.
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?
You can do that even with the ESP8266. It’d barely take a few hours of work if you’re familiar with MCU-programming, especially if you use the easy-to-use Arduino-core ( https://github.com/esp8266/Arduino ) for it. But sure, yes, you can do it with ESP32, too. Both WPA1 and WPA2 are supported on both chips.
Awesome, thanks! I wanted to use the ESP32 because it has a DAC, which I need for my project. With the ESP8266 I’d have to include another chip in the design.
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 :)
Don’t forget, you can get a lot of mileage out of the PWM timer with a simple RC low-pass filter. I’ve used that in lieu of a DAC in many projects…
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…
I’ve tried the ESP8266, and at least when I was trying it, it was rather incomplete. It didn’t even have garbage collection.
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.
I have a basic breakout board for the ESP3212 module for sale on Tindie (ESP3212 not included). As soon as someone confirms that it works I can order the prototype for the next version with features similar to the NodeMCU boards. What do you think would be a fair price for that (with ESP3212 included?
For now, here’s the simple one: https://www.tindie.com/products/dude8604/esp3212-breakout-board-alpha/
Is there a reason that the ground pad on the bottom of the ESP3212 isn’t connected on your breakout board? Maybe to enable assembly without reflow oven or hot-air pencil? The ESP3212 datasheet doesn’t say if this connection is absolutely essential.
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.
I meant the large ground pad on the bottom of the ESP3212 board, not the three ground pads on the edges. See this picture : https://statics3.seeedstudio.com/seeed/img/2016-09/O6q3SFJ9zQg9YANP2ho7xmMW.jpg
Can’t wait for LUA on ESP32 !!!!
Can’t wait for MicroPython on ESP32.
Can’t wait for on the ESP32!
Check out pycom.io. They’re selling ESP32 based boards with micropython preloaded!
Hi Philip,
It true. It hasn’t been confirmed yet that Breakout Board Alpha works with ESP3212. As soon we will have a positive comment on that, we will post it here.As about the price… We don’t have a clue!
I can wait for LUA on ESP32 (:
Woah, big respect to Espressif, Sprite_tm and Igrr for monitoring this thread and answering these questions. REally keen to get my hands on a few of these.
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?
iggr is indeed a colleague of mine; we both work for Espressif.
Thank you.
The goodwill you two are generating is beyond measurable, in the long term.
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?
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.
They are pushing *way* too hard for you to use their cloud-stuff for my taste, and it looks like you have to jump through a lot of hoops if you don’t want any of it.
So, basically, Electric Imp all over again, but not quite as bad?
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.
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.
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?
> 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
Or how about an article about the details of ESP-Now (ACK/No ACK, CRC/No CRC, Multipoint/Single-Point, tests)
OK. This article says 160 MHz dual core, but the following ExpressIf ESP32 marketing page shows 240 MHz dual core: https://espressif.com/en/products/hardware/esp32/overview . Are the marketing pages just showing what it is overclockable up to? Perhaps 160 MHz is the guaranteed stable clock rate. Anyone with more definitive information on this?
If you’d scroll up you’d see Sprite_tm say that 160MHz is the default clock-speed, but you can overclock to 240MHz, if you wish.
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…..
“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.
Check out pycom.io. They’re making esp32 boards preloaded with micropython!
Micropython support is already there. Pycom.io has released a board that uses the esp32 preloaded with micropython firmware.
“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…
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
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 https://github.com/espressif/esp-idf/blob/master/components/esp32/include/esp_ipc.h.
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.
Hello Mr. Thanks by great article about ESP32. Is it possible ESP32 programming in Arduino IDE? Thank you again.
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 ?