ESP32 development overview

[sylvioalves]

ESP32 Development Status

PERIPHERAL	ESP32	ESP32-S2	ESP32-C3	ESP32-S3	ESP32-C6	ESP32-C2
CPU	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
IRQ	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
TIMERS	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
UART	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
I2C	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
SPI FLASH	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
SPI FLASH (Octal)	N/A	N/A	N/A	:heavy_check_mark:	N/A	N/A
SPI RAM	:heavy_check_mark:	:heavy_check_mark:	N/A	:heavy_check_mark:	N/A	:heavy_check_mark:
SPI RAM (Octal)	N/A	N/A	N/A	:heavy_check_mark:	N/A	N/A
SPI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
Cryptography	:x:	:x:	:x:	:x:	:x:	:x:
Wi-Fi	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:
BLUETOOTH	:heavy_check_mark:	N/A	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
IEEE802.15.4	N/A	N/A	N/A	N/A	:x:	N/A
BT Mesh	:x:	:x:	:x:	:x:	:x:	:x:
GPIO	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
TWAI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
E-FUSE	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:	:heavy_plus_sign:
ADC	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:	:heavy_plus_sign:
ADC DMA	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:
DAC	:heavy_check_mark:	:heavy_check_mark:	N/A	N/A	N/A	N/A
DAC DMA	:x:	:x:	N/A	N/A	N/A	N/A
MCPWM	:heavy_check_mark:	N/A	N/A	:heavy_check_mark:	:x:	N/A
LEDPWM	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
PCNT	:heavy_check_mark:	:heavy_check_mark:	N/A	:heavy_check_mark:	:x:	N/A
TRNG	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
LCD	N/A	N/A	N/A	:x:	N/A	N/A
DMA SPI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
WATCHDOG	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
LOW POWER Light sleep/Deep sleep	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:
RTC	:x:	:x:	:x:	:x:	:x:	:x:
USB OTG	N/A	:x:	N/A	:x:	:x:	:x:
USB CDC	N/A	N/A	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
ETH MAC	:heavy_check_mark:	N/A	N/A	N/A	N/A	N/A
SDHC	:heavy_check_mark:	N/A	N/A	:heavy_check_mark:	:x:	N/A
SDIO slave	:x:	:x:	:x:	:x:	:x:	:x:
CAMERA	N/A	N/A	N/A	:heavy_check_mark:	N/A	N/A
I2S	:x:	:x:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
ULP	N/A	:x:	N/A	:x:	:x:	:x:
SMP	:x:	N/A	N/A	:x:	N/A	N/A
AMP	:heavy_plus_sign:	N/A	N/A	:heavy_plus_sign:	N/A	N/A
FLASH ENCRYPTION	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
DFS	:x:	:x:	:x:	:x:	:x:	:x:
OPENOCD	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
MCUBOOT (Zephyr port, basic cyber security)	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
MCUBOOT (Espressif port, secure boot V2)	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:

Last update: 24/Sep/2024

• :heavy_check_mark: Feature is supported.
• :heavy_plus_sign: Work in progress.
• :x: Feature is not supported
• N/A: Not applicable to this device.

Introduction

This RFC gives an overview of features and enhancements we plan to contribute for Espressif's ESP32 SoC device. It is not intended to be a proper roadmap but it gives some information about our effort on having more support for Zephyr RTOS.

Problem description

Currently, ESP32 support consists of a few peripheral implementations as such as GPIO, UART and I2C, which limits device usage on Zephyr. There are missing peripheral drivers as such as WiFi and BLE that are very often requested by the community, but lack implementation.

Proposed change

The proposal is to enable the powerful features that ESP32 SoC can offer, starting by bringing up WiFi subsystem. Meanwhile, we shall also work on developing yet unsupported peripheral drivers.

Detailed RFC

Initial Development

As there have already been some work on the WiFi bring up, a few modifications can be listed below describing initial requirements:

• Add ESP-IDF bootloader that handles SoC initialization (cache, MMU and partition tables). In long term, Zephyr's bootloader might be supported as well.
• Set XIP support by default to support ESP-IDF bootloader.
• Update linker script with proper flash, ram sections and symbols map.
• Update clock settings and entropy drivers.
• Add timer/counter support.
• Add NVS support.
• Add Wifi sources and network drivers.

WiFi Driver and Network Integration

We have already implemented the WiFi adapter driver, which binds ESP32 internal WiFi to Zephyr's ETHERNET_L2 layer. However, Zephyr has yet no support for WiFI SoC that runs as non-offloaded driver. It means that creating a network device following subsys/net/l2/wifi/wifi_mgmt.c API does not allow binding to the ETHERNET_L2. There is no such implementation for a WIFI_L2 layer, which would allow using WIFI_MGMT API to integrate with ETHERNET_L2 layer.

This will be addressed in another issue focused on network integration and user API.

ESP32 HAL Module

To keep the folder structure in sync with other vendors, and to update ESP-IDF source to version 4.2, repository modules/hal/esp-idf shall be updated to modules/hal/espressif. Only minimal and necessary ESP-IDF sources shall be included in this repository, which includes source files, adapter layers and symbols to handle internal calls. It will require changing west.yml to point to this new branch.

Peripherals

The list below shows currently unsupported peripherals. We plan to start developing a few drivers in long term. Porting all the components is tricky due to FreeRTOS dependency in the current ESP-IDF implementation. SPI related code has special considerations due to dual-core SoC architecture and XIP (code execution from Flash). BLE and WiFi share the same RF radio, which implies handling their coexistence by hardware or software. ESP-IDF already takes care of everything but the porting is not straightforward. Also, we still have to analyze issues regarding multi-core support, SMP and power management.

• SMP
• DMA
• ULP
• ADC
• DAC
• CAN
• I2S

Future Plans

Future Devices

It is well known that Espressif has other chipsets on its platforms. We plan to add support to them as well when a reasonable ESP32 support on Zephyr is achieved for product level usage. For the time being, there are plans to add support for (not in any chronological order):

• ESP32-H2 (TBD)
• ESP32-H4 (TBD)
• ESP32-P4 (TBD)

More may be added to the list as Espressif adds more chipsets to its linecard.

[rftafas]

Hello,

By when we can expect support for ESP32-S3 in Zephyr ? As per timeline given on https://www.espressif.com/en/news/new_operating_systems_in_ESP32 this would have available by Q1. Is there any new timeline ? I have asked this question in other forum but no timeline has been provided. Also is there any development PR or branch that can be referred.

Status is pretty much the same and the link for this thread is above. We are still working on tasks that are part of our plan for ESP32-S3 (AMP, Protected Modes, etc).

I'd like to point out that ESP32-S3 without AMP and AI/DSP extensions (which are far away on roadmap) is pretty much ESP32S2 plus BT. Furthermore, ESP32-S2 without USB is pretty much ESP32 minus BT and minus AMP. As of today and for a while, even if we put all efforts to bring up ESP32-S3 CPU support with WiFi and Bluetooth, there won't be much that you can do with ESP32-S3 that you cannot do with ESP32 and, except for Bluetooth, ESP32-S2.

@GuptaAshi-Eaton Is there any reason on why ESP32-S3 is mandatory?

[edit: AMP PR here]

[sam131208]

@rftafas

You mentioned the low power consumption of the ESP32, which is very important in product deployment. When can we test it?

[rftafas]

@rftafas

You mentioned the low power consumption of the ESP32, which is very important in product deployment. When can we test it?

We are working on it, but I would not hold my breath waiting... It will take a while.

My general suggestion is to rely on already released features for immediate/close product development.

[mickeyl]

I have started work on adding support for the ESP32 CAN controller.

Awesome, is there any progress yet?

[rftafas]

FWIW: https://www.espressif.com/en/news/Zephyr_updates

[henrikbrixandersen]

I have started work on adding support for the ESP32 CAN controller.

Awesome, is there any progress yet?

Yes. I will soon post a PR. The TWAI pinctrl PR was already merged (https://github.com/zephyrproject-rtos/hal_espressif/pull/108).

[Red-M]

I am interested to see the S3 supported for some various reasons of my own. Mainly looking for a dual core MCU with 34+ GPIO pins and USB device support.

[rftafas]

I am interested to see the S3 supported for some various reasons of my own. Mainly looking for a dual core MCU with 34+ GPIO pins and USB device support.

Question @Red-M : do you intend to use dual core AND networking/BT with Zephyr? I would suggest first to study that with regular ESP32 and find out the limitations first and check if it suits you, as enabling networking/BT and SMP are not compatible. We are working on AMP, though.

[Red-M]

Nope, no networking but I need USB HID and the above

[enthunilu]

Hello,

Is there a near future plan to have USB support for ESP32-S2/S3 ?

[rftafas]

Future plan, yes, but we probably won't get to it until we are done with current endeavors. FWIW, we noticed your USB support request.

[Suhas-MS]

Hello, I have a requirement for SPI slave using ESP32. Is this supported now or will it added in the future?

[rftafas]

Hello, I have a requirement for SPI slave using ESP32. Is this supported now or will it added in the future?

@Suhas-MS, it's not supported yet, it's on backlog, it's not on any schedule/roadmap yet. I suggest creating a request for that or DIY if you are on a tight schedule. Usual advice to rely on already released features still apply.

[sam131208]

Hello, Are there any plans to support I2S? I wrote a simple I2S driver before, but when I ported from zephyr ver3.1 to ver3.2, it didn't work correctly. I hope zephyr can add I2S support to the list.

[rftafas]

Hello, Are there any plans to support I2S? I wrote a simple I2S driver before, but when I ported from zephyr ver3.1 to ver3.2, it didn't work correctly. I hope zephyr can add I2S support to the list.

@sam131208 , it is not on the horizon yet and I wouldn't hold my breath either. I strongly encourage you to share your work on GH. It may be a starting point to fix your issue, points you towards a nice contribution and you may have it working earlier...

[sslupsky]

Is there support for ESP32-C6?

[rftafas]

Not yet. Unless you need specifically for 802.15.4 and Wi-Fi 6, you can do fine with C3.

[rftafas]

ICYMI: https://github.com/zephyrproject-rtos/zephyr/pull/53699

[wpalm]

Is support for the LCD peripheral in ESP32-S3 on the roadmap?

[rftafas]

@wpalm Yes, it is, but, no, it was not started yet. If you plan to engage, let us know.

[EricNRS]

https://github.com/zephyrproject-rtos/zephyr/pull/59918 has been merged, so we can mark TWAI as supported for ESP32-S3.

[RBartonMesh]

Is there a plan to support ESP-IDF v5.x?
Am aware that this is a major rev with breaking changes. However, some ESP32 devices are being supported / SDKs are being implemented solely on v5; would love to get access to Zephyr there as well.

[rftafas]

Is there a plan to support ESP-IDF v5.x? Am aware that this is a major rev with breaking changes. However, some ESP32 devices are being supported / SDKs are being implemented solely on v5; would love to get access to Zephyr there as well.

We are currently refactoring the way things are used and build. We are cleaning the 'ESP-IDF components' that are present on hal_espressif because, first, we don't use it and, second, it creates confusion. So, yes, next hal_espressif will have everything needed for the newer devices (i.e. comparable to ESP-IDF 5.1). That said, PTAL: https://github.com/zephyrproject-rtos/zephyr/issues/54453 . BUT... First we must complete the boards and SOCs reorganization to be more like other manufacturers. PTAL https://github.com/zephyrproject-rtos/zephyr/pull/58454

[EricNRS]

Lucas added SPIRAM support for the S3 with https://github.com/zephyrproject-rtos/zephyr/commit/c435dea191f9d802112766d1491885c31c8845aa, so we can mark that as complete (not the octal support, though, since that requires IDF v5).

[aelray]

Hi, it's mentioned that USB CDC is already supported for the ESP32-S3. However, when I try to build my code, which is based on the CDC ACM sample in samples/subsys/usb/cdc_acm I get the error devicetree error: ./app.overlay:7 (column 1): parse error: undefined node label 'zephyr_udc0'. Am I doing something wrong?

[EricNRS]

Probably best to start up a thread in Discord or a discussion here in github for that. I am personally using the usb_serial instead of uart0 for flashing, debug, and console and that is CDC ACM. You may want to clarify in your discussion if you want to use that or use the CDC ACM over standard USB in parallel with UART0.

[aelray]

Probably best to start up a thread in Discord or a discussion here in github for that. I am personally using the usb_serial instead of uart0 for flashing, debug, and console and that is CDC ACM. You may want to clarify in your discussion if you want to use that or use the CDC ACM over standard USB in parallel with UART0.

Is there an example on how to use the usb_serial?

[EricNRS]

https://discord.com/channels/720317445772017664/883444902971727882/1133332413989257298

[rftafas]

Please note the difference between USB-CDC (similar to the one on ESP32C3) to USB OTG Console (similar to the one achievable on S2).

[edit] typos and this link: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/usb-otg-console.html

[joaotavora]

~It would seem that a recent commit (6b57b3b786be8558e7e310b849e0b97bd1eae45c) broke most/all esp32 builds. Building the hello-world sample:~

~Is this expected? Should I open a new issue or is it being tracked already? I was looking to use SPIRAM on the S3 (as noted here: https://github.com/zephyrproject-rtos/zephyr/issues/29394#issuecomment-1659913663)~

nevermind, seems I just forgot to west update to update zephyrproject/modules. sorry for the noise

[EricNRS]

nevermind, seems I just forgot to west update to update zephyrproject/modules. sorry for the noise

I was just going to say that. I have seen that same issue due to a mismatch between the HAL and zephyr projects :) Glad you resolved it quickly.

[joaotavora]

On the topic of SPIRAM support on the S3 (https://github.com/zephyrproject-rtos/zephyr/issues/29394#issuecomment-1659913663), is there any kind of ETA for Octal-mode SPI support?

[EricNRS]

@sylvioalves We can mark the ADC as supported for ESP32-S3. Thanks your help with the ADC changes!

[TiboDevC]

Hello, Are there any plans to support I2S? I wrote a simple I2S driver before, but when I ported from zephyr ver3.1 to ver3.2, it didn't work correctly. I hope zephyr can add I2S support to the list.

@sam131208 , it is not on the horizon yet and I wouldn't hold my breath either. I strongly encourage you to share your work on GH. It may be a starting point to fix your issue, points you towards a nice contribution and you may have it working earlier...

Hi @rftafas , is there any major technical obstacles/difficulties to develop the I2S driver?

[rftafas]

Hi @rftafas , is there any major technical obstacles/difficulties to develop the I2S driver?

The main difficulty is that we have been busy with other components. It should be fairly straightforward as long as you use hal_espressif. I also suggest looking into how I2S was made on ESP-IDF and how other Espressif Peripherals on Zephyr using hal_espressif.

[TiboDevC]

Hello, Are there any plans to support I2S? I wrote a simple I2S driver before, but when I ported from zephyr ver3.1 to ver3.2, it didn't work correctly. I hope zephyr can add I2S support to the list.

@sam131208 , it is not on the horizon yet and I wouldn't hold my breath either. I strongly encourage you to share your work on GH. It may be a starting point to fix your issue, points you towards a nice contribution and you may have it working earlier...

@rftafas has you suggested, I started an I2S driver for esp32s3 here https://github.com/zephyrproject-rtos/zephyr/pull/62155 this is a starting point.

It does not work well yet, I am struggling with DMA (there is an overflow somewhere). With west build samples/drivers/i2s/echo example, it starts receiving/transmitting then stops quickly due to k_mem_slab_alloc failing in the DMA callback. I am debugging this part but I guess there are some Zephyr mistakes to be found.

As I am new in Zephyr, if someone could help me pushing/reviewing this driver it would be very helpful :)

[FARLY7]

I couldn't find this mentioned anywhere: When both WiFi and BLE are stated as supported, is this also with software coexistence? In my case, I would like to both scan for BLE advertisements and operate WiFi in promiscuous mode, which is possible in ESP-IDF.

[rftafas]

I couldn't find this mentioned anywhere: When both WiFi and BLE are stated as supported, is this also with software coexistence? In my case, I would like to both scan for BLE advertisements and operate WiFi in promiscuous mode, which is possible in ESP-IDF.

It should work. It uses software coexistence, that is correct. Using both consumes a lot of RAM, so, if your application ends being big, you will face some challenges.

[jkorenj]

Hello, I am trying to implement software coexistence on ESP32-C3. When I try to enable it with CONFIG_ESP32_WIFI_SW_COEXIST_ENABLE it throws error to this link http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_ESP32_WIFI_SW_COEXIST_ENABLE If I understand correctly this feature isn't implemented yet.

Can you help me point to some resources where I can find some examples how to implement it.

Thank you.

[rftafas]

Can you help me point to some resources where I can find some examples how to implement it.

Thank you.

Main recommendation is to use hal5.1 - the things you will need for that are listed on the C6 discussion.

I'll double check, but several "ESP32" kconfigs also applies for other ESP32xx devices. Maybe start checking this. It is common to take "ESP32" prefix/suffix as a family name in disregard that we also have a device named ESP32.

If it is indeed ESP32 only, most likely what is there for ESP32 can be the base for C3.

BTW, it happens the other way around. Some configs for specific SOCs (S2, C3, S3...) are the same as the one for "ESP32", changing the name only. We are discussing in maybe using a better prefix/suffix.

[jkorenj]

Thank you.

I tried building it with the same configuration for ESP32 and the build is successful. I will try to use this as a starting point for ESP32 C3.

Regards.

[FARLY7]

Thank you.

I tried building it with the same configuration for ESP32 and the build is successful. I will try to use this as a starting point for ESP32 C3.

Regards.

Interested to know how you get on @jkorenj, we are also using the ESP32-C3.

[jkorenj]

Hello,

I check a little bit further and I found drivers/wifi/esp32/Kconfig.esp32.

config ESP32_WIFI_SW_COEXIST_ENABLE
    bool
    help
      Software controls WiFi/Bluetooth coexistence. Not supported yet.

This is my first project based on Zephyr, and maybe I don't understand it correctly, but it seams to me that coexistance isn't supported for any of the ESP32 devices. I can't test it right now, because I don't have ESP32 board.

Thank you.

[sylvioalves]

@jkorenj You can use Wi-Fi and BLE in the same application. Coexistence is handled by HW. The flag you mentioned is a way to allow ESP32 to handle coexistence over SW. That specific function is yet to be supported.

[jkorenj]

@sylvioalves Thank you. But in this case I don't understand why the flag is needed. I did a demo project with esp-idf, based on freeRtos I couldn't manage to implement coexistence without coexistence flag.

Now I want to implement the same thing based on Zephyr. I initialized two threads, one for BLE (hr monitor) and second one for WIFI (echo client) both based on sample code. But connection is really unstable.

[rftafas]

@sylvioalves Thank you. But in this case I don't understand why the flag is needed. I did a demo project with esp-idf, based on freeRtos I couldn't manage to implement coexistence without coexistence flag.

The flag is there because we do have plans to implement it. As most users are ok with HW coex, we didn't add any priority to it. SW Coex is needed when there is high traffic, hence, why you couldn't do it - check its description on ESP-IDF.

Now I want to implement the same thing based on Zephyr. I initialized two threads, one for BLE (hr monitor) and second one for WIFI (echo client) both based on sample code. But connection is really unstable.

Because this seems to be a high traffic scenario. This is the first case that came to our awareness. Please, report it as a feature request.

As usual, base product design only on features that are already available.

[jkorenj]

Sorry for late response. I managed to implement simple demo that runs heart rate application for BLE connection and in parallel it connect to the mqtt broker to publish some data. As you said it works without SW flag enabled. It looks like I had really bad signal strength.

I decided to go and try a little more on Zephyr and I decided to implement hci uart sample on ESP32-C3. Is this feature implemented for ESP32 boards?

I started with the espressif example and I managed to get it working straight away. So I can confirm that the host side is working correctly, because I was able to see BLE device on my phone and connect to it. But I can't really get it working with zephyr. I did one demo project to confirm UART is set up correctly and I can see that host side sends the data to ESP32. I also see that something was received and that state machine moves from state to state. But nothing is seen on the Bluetooth. But other than that no further communication happens on line.

Thank you.

** Edit: Looks like I managed to make it work. The problem that I had was that hci uart on zephyr seems to send different prefix for static address read than the espressif example.

I was using: STATIC const uint8_t read_static_address_command_complete_prefix[] = { 0x0e, 0x1b, 0x01, 0x09, 0xfc }; https://www.funkthat.com/gitea/jmg/micropython/commit/c4af714d58213bb23b81f3736f785d897e60ac77?lang=zh-TW

but got response: static const uint8_t read_static_address_command_complete_prefix[] = { 0x0e, 0x04, 0x05, 0x09, 0xfc };

If I get any other info I can add here.

[Alex-Stanfield]

Hi there, are there any plans to implement the RMT controller for Zephyr?? I need to output a square with variable frequency (ramp-up, stable, slowdown) in order to control stepper motors. Any plans or ideas around this? Thanks!

[rftafas]

Hi there, are there any plans to implement the RMT controller for Zephyr?? I need to output a square with variable frequency (ramp-up, stable, slowdown) in order to control stepper motors. Any plans or ideas around this? Thanks!

Why not PWM? LedC and MCPWM are supported already.

[davidbuzz]

ArduPilot uses the RMT peripheral under FreeRTOS for reading RC-in on the esp32/esp32s3 ... https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ESP32/RmtSigReader.cpp incase u are looking for a use-case for RMT. :-)