Over the past year, Espressif has continued working on Zephyr, adding not just a porting layer and peripheral support, but also actively contributing to Zephyr tools, libraries and bugfixes. However, we understand that tracking this development through commits is somewhat painful. So, the purpose of this article is to provide a clear update on the features we have added and clarify the direction of Espressif’s support for this project in the future.

Road to Low-Power Modes

Zephyr is changing from Pin Mux to Pin Control. This migration is important, and we are pleased to announce that migration for currently supported peripherals in the ESP32 series of SoCs has been completed. This development will affect those working on architecture support more than it will affect Zephyr users. But let us take a look at what Pin Control means in the first place.

Pin Control is a new mechanism which provides a better way for configuring IO pins in terms of direction, and pull-up/pull-down enablement. More importantly, Pin Control assigns pins to a particular peripheral. Although it does not impact users too much, its overall significance should not be underestimated. By completing the migration from Pin Mux to Pin Control, we have reached a major milestone towards enabling low power for ESP32 devices. Without this work, any development would have to be reviewed and maybe refactored.

Wi-Fi Manager Support

When we started porting ESP32 to Zephyr, we found out that ESP32 was already being widely used as the off-loaded (off-chip) Wi-Fi solution of choice. Most systems had a different CPU running Zephyr, which would first get connected to ESP32 (sometimes, even, to ESP8266) through a serial port, and then it would get access to Wi-Fi.

ESP32 is great for such use, and we were happy to be the first, on-chip, Wi-Fi-enabled device to be ported to Zephyr. However, we felt that our device could do more: ESP32 was still not using the known APIs developers would turn to for configuring the off-loaded Wi-Fi. Eventually, we achieved that too, and we are pleased that we managed to support the Zephyr Wi-Fi manager. While it does not add any new capabilities, it makes controlling the ESP32 Wi-Fi system familiar to those already using Wi-Fi Manager APIs.

Zephyr and Parallel Processing on ESP32

Asymmetric Multiprocessing (AMP) is probably the most impactful development of Espressif’s support for Zephyr. Basically, AMP means using every core on a system as a standalone processor that runs its own tasks/firmware/OS, etc. In a sense, this is like parallel computing in a single microcontroller, which has actually not been explored in ESP-IDF yet.

Zephyr’s AMP solution differs from that of ESP-IDF in terms of the way the multicore microcontroller is used. So far, ESP-IDF has focused on SMP (symmetric multiprocessing), whereas Zephyr’s equivalent solution was AMP, either due to restrictions or due to a willingness to provide various alternatives. For us, the prime objectives of providing AMP on ESP32 are:

• Network offloading: one core takes care of the load, while the other one is still dedicated to managing user applications.
• Parallel Embedded Software: this allows for non-critical routines to be executed separately from critical routines.
• Redundant processing: the same firmware can run in parallel on ESP32.
• General Parallel Processing: this offers two MCUs in one package.

For the time being, this piece of work is a proposed change (a push request). Users can already test it, while we wait for approval. So, in the meantime, why not start thinking about new possibilities?

Peripheral Support

While peripheral support is not the only task for supporting an RTOS, it is among the most important ones. ESP32 devices are resourceful, but it always takes much effort to get them fully supported. This is why we are truly grateful to those developers from the Zephyr community, who decided help us port some peripherals. Thus, the current porting status of the ESP32 family is as follows:

Legend explanation:

• Beta – Feature is developed, or is at the final-testing/merge stage.
• WIP – Work in progress by Espressif Team
• Community – Work in progress by community members
• Yes – Feature is supported.
• No – Feature is unsupported
• N/A – Not applicable to this device.
• Support depends on specific scenarios.

Why is there no ESP32-S3 in the table above?

While we are already working hard to include ESP32-S3 here, it should be noted that the case of this SoC is pretty unique. ESP32-S3’s dual-core capacity and Bluetooth make it quite different from ESP32-S2. Then, what makes ESP32-S3 different from ESP32 is the former’s USB-OTG capability. It is also important to note that ESP32-S3 has a powerful CPU, so without a good power control it can drain batteries.

In general, the development of ESP32-S3 would first need to fulfil the following three requirements before being included in the Zephyr project:

• multicore support, which is what we are trying to achieve with AMP (this is a merge request at present);
• low-power modes, which we have already started working on;
• support for USB-OTG, which is already scheduled for the near future.

Until we fulfil the above-mentioned three requirements, developers wishing to target ESP32-S3 should practically stick to ESP32 or ESP32-S2, which are currently the best choices for running Zephyr.

Future Direction

Espressif plans to continue its support for the Zephyr project. Also, we are excited about a particular solution we put forward: Zephyr is the first RTOS to support an AMP solution for the ESP32 series of chips. This is huge on its own, as it enables parallel processing on a microcontroller!

Needless to say that we have our own ideas about how to move forward, but we would really appreciate it if you shared yours with us, so that we can jointly shape our future projects.

Relevant links

• Check out our progress since the last status update.
• Road from pinmux to pinctrl
• AMP Merge Request on GitHub