Catch a rare glimpse of the life behind the secrete doors of Espressif, the manufacturer of the IoT rock-star chips ESP8266 and ESP32.

My friend Squix and I compiled a list of questions to Ivan Grokhotkov  Director of Software Platforms at Espressif. Ivan is one of the main drivers behind the ESP8266/Arduino project. Early in 2016 he joined Espressif and moved from St. Petersburg, Russia to Shanghai to support their software team. Before Espressif Ivan worked for SPB TV, a manufacturer of set-top boxes and for Intel in Russia.

Hi Ivan. Thank you for agreeing to this interview. Let’s start with the ESP8266. What was your first project you ever built with the ESP8266 and what was the reason you got involved with the ESP8266/Arduino project?

My first project for the ESP8266 was the AT protocol library, which I have started as an attempt to replace Espressif’s AT application with something less quirky. When I had started writing atproto, I thought I would implement both ends of AT protocol — DCE and DTE. When atproto was mostly feature complete, I have started pondering how to accommodate the asynchronous nature of the protocol in a sequential program, running in a system without threads or tasks. Toying with different approaches with coroutines, looking at other implementations, I have gradually come to realization that I can implement similar sequential API on the ESP8266 itself, without going through the trouble of handling AT commands. At that time I was mostly using mbed for my hobby projects, so naturally my first choice was to write an API layer similar to mbed on top of ESP8266 non-OS SDK. That was October 2014, and the RTOS SDK wasn’t out yet.

Mbed turned out to be quite ARM-specific (although upon revisiting mbed internals year later, I think my first impression wasn’t correct), so I turned to Arduino, which I have never personally used up to that point.
Writing the basics of the Arduino core wasn’t as hard as packaging everything together. I think I have learned a lot at that time. There were a few people who were kind enough to beta test the early Arduino environment for me during the first few months. During winter 2015 I have gradually lost interest in the project; it was only in April when Richard (who maintains the esp8266 community forum) has encouraged me to release the code publicly. All the rest is (commit) history.

And I would add that the ESP8266/Arduino project really became a success story! In April 2016 you started working for Espressif, the company behind the ESP8266 and the ESP32 and you moved to Shanghai. How would you describe your current role at Espressif?

Espressif makes fantastic hardware, with very limited resources and a small team. I came to Espressif with the goal of bringing Espressif’s software efforts on par with the hardware. This is pretty much what I was trying to do for the last year. Talking to engineers about software design, doing code reviews, formalizing development workflow, code style, and documentation flow, helping QA and hardware teams, and writing parts of ESP-IDF took for the bulk of my work time last year.

It was a very clever move from Espressif to hire those passionate individuals who earned a solid reputation in the ESP8266 open-source community. Besides you how many more were hired? Did all of them move to Shanghai or are you now a globally distributed team?

Jeroen, known to many as Sprite_TM, has been an Espressif employee for some time already when I have joined. He is awesome and I am grateful for his support and the great amount of work which he tackles. Jeroen made a lot of impact arguing about the philosophy and the contents of ESP32 Technical Reference Manual, which could otherwise end up being similar to the ESP8266 documentation.

It was very fortunate for our team that Angus Gratton had accepted the offer to join Espressif last summer. He did fantastic work on esp-open-rtos, and the ESP-IDF is in many ways affected by things learned from that project. Angus is great to work with, his attention to detail sets an example for all our team, and he is always positive and encouraging.

Hristo has written big chunks of the ESP8266 Arduino core and libraries, and the immensely useful ESPAsyncTCP and ESPAsyncWebServer libraries. He is now working on the ESP32 Arduino core, which is coming along nicely.

Tuan has written popular MQTT libraries for the ESP8266 and is now working on Audio-related projects in Espressif.

Myself and Jeroen work in Shanghai, others work remotely, and visit Shanghai occasionally.
Connectivity issues between China and the rest of the world pose occasional trouble for us. We keep looking for ways to work together effectively, and we plan to grow our global team in the future.

In your experience what is the most notable difference between working with Russian colleagues and Chinese colleagues? How is their approach at problem solving different, if at all?

I find that engineers in China are more subject to pressure from managers and (indirectly) from customers than their Russian counterparts. Sometimes this means that problem solving slides into looking for quick patches, to meet deadlines. On the other hand, Chinese colleagues do a lot better at sticking to the plan and the schedule. Also I do admire the part of Chinese working culture which puts customers’ interests very high.

Another notable difference was lack of criticism (or “constructive confrontation”, as it is called in Intel) from my colleagues when discussing some software design choices. I am happy that some of my colleagues can now say “no, this is a bad idea” to my suggestion, but this doesn’t happen as often as I would like.

You used to work for a manufacturer of settop boxes and also for Intel in Russia. How are these experiences helping you at Espressif?

I have learned a lot about the ways organizations work while I was at Intel (not to mention all the fun projects I had a chance to take part in). Espressif is obviously much smaller than Intel, but the interactions between teams and between people happen in similar ways. At SPB TV I wrote a lot of code, both for desktop and embedded, which was a great learning experience. Working with customers and ODMs was another aspect of my work, and I got to know a lot of things ranging from managing customers’ requirements to release management. All these things are also part of my daily routine at Espressif.

What is currently your main focus of development with the ESP32?

As the ESP-IDF is growing to support most of the ESP32 functionality, the focus for me shifts towards development and debugging tools, package management, simulation environments, unit testing and test coverage tools, documentation, and other things which can help developers be more productive. Another notable area is related to working with legacy code, and efforts to make parts of WiFi stack open source. Frankly I’ve done much less on this than I have planned — we felt that getting features into place was more important to developers and our customers at this stage.
Other chunks of work are related to supporting targets other than the ESP32 in the ESP-IDF, and implementing some of the sleep-related functions of the ESP32.

Will we soon have a Arduino/ESP32 platform with comparable maturity to the ESP8266 or will the two platforms merge into one?

Our first goal is to reach release 1.0 of the ESP32 Arduino core, with major ESP8266 libraries supported there. We will try to keep ESP8266 sketches compatible with the ESP32, and will share code between projects where it makes sense. Merging two platforms into one is technically possible, but it is not entirely clear if the gains will offset the efforts.

What do you think about the ESP32? Is it just a better, more powerful replacement for the ESP8266 or do the two chips aim at different applications?

ESP32 can be considered an ESP8266 replacement in some cases, while in other cases ESP8266 may still be more attractive because of the lower price point. See table below as for how to select Espressif IoT solutions.

The ESP32 is advertised as very power efficient. What power consumption can we expect in deep sleep?

In the first silicon revision of the ESP32, most applications will see ~5uA supply current in deep sleep mode, due to RTC fast memory being powered on by default. New silicon revision which is coming in February will not need RTC fast memory to be powered on, so power consumption in timer wakeup mode can be 1-2uA lower.

Is it realistic to expect that ESP-IDF will be a true HAL that abstracts differences between ESP32 and future Espressif chips?

ESP-IDF will indeed serve as abstraction layer for the core system and main peripheral drivers, supporting the ESP32 and future chips. This includes support for different RTOSes and processor architectures. Parts of these additional abstraction layers are already work in progress, some will come later along with new chips entering the market.

If so, will it ever support ESP8266 / ESP8255? What about the NON-OS and RTOS stacks? How long is Espressif going to continue investing in three different SDKs?

Support for the ESP8266 in ESP-IDF is possible, although at this point we have not committed resources to that task. Putting my developer hat on, I would very much like to have everything supported in the single SDK. On the other hand, we can not deprecate the existing non-OS and RTOS SDKs for the ESP8266, because that’s what our existing customers currently use. So the question regarding ESP8266 support in the ESP-IDF is more a question of supporting 3 different ESP8266 SDKs rather than 2.

As announced last year, Espressif will support the ESP8266 and the SDKs for 12 years starting from January ’14. The actual rate of updates will depend mostly on feedback from customers and developers, but at this point both ESP8266 SDKs are mostly being maintained, rather than actively developed.

You are using the ESP32 in a RC Model. What is the role of the ESP32 on the plane? Have you been flying RC models before or you just started it for the ESP32?

I have started flying RC models when I came to China. Reading a number of RC related forums I have noticed that WiFi is usually considered by RC enthusiasts as “not good enough” for the purpose of remote control. I tried using a pair of ESP8266 boards: one board inside a conventional “RC transmitter”, stripped from the internals except for the analog sticks and switches; another one inside the RC model, attached to servos and the ESC. Hardware-wise, I have used Wemos D1 mini modules, which need only a 5v supply along with some pin headers. I am using ESP-NOW library which allows two ESPs to communicate without using WiFi in infrastructure mode (as in, STA connecting to an AP). This combination turned out to be very reliable. I should take time one day to document the whole project.

The new version is based on the ESP32, and I am also running a simple flight stabilizer there, which takes input from an MPU9250. I am eagerly waiting for ESP-NOW library to be ported to the ESP32, and using UDP protocol in the mean time.

You recently 3D printed a part for your RC model. Which 3D printer are you using and what exactly did you print?

The printer is Formlabs Form 1+, and the part which I have printed was the brushless motor mounting plate. The original one cracked when the propeller blade hit a stone during a not very successful landing. I have used OpenSCAD software to design the replacement part, and liked the experience very much. It is the tool for the kind of person who prefers, for example, LaTeX to Word.

Squix and I are very grateful that Ivan took the time to answer our questions at great length!