Add Espressif RMT driver by joelguittet · Pull Request #101448 · zephyrproject-rtos/zephyr

joelguittet · 2025-12-22T23:47:00Z

Add initial version of the Espressif RMT driver.

A sample application is created to demonstrate the usage.

This pull-request depends on an update of hal_espressif: zephyrproject-rtos/hal_espressif#510

kartben · 2025-12-23T07:04:56Z

include/zephyr/drivers/misc/espressif_rmt/rmt_encoder.h

+ *      - ESP_ERR_NO_MEM: Create RMT bytes encoder failed because out of memory
+ *      - ESP_FAIL: Create RMT bytes encoder failed because of other error
+ */
+esp_err_t rmt_new_bytes_encoder(const rmt_bytes_encoder_config_t *config, rmt_encoder_handle_t *ret_encoder);


You're writing a zephyr driver, please return zephyr error codes :)
Also use @retval for documenting the discrete error values

kartben · 2025-12-23T07:06:21Z

dts/bindings/misc/espressif,esp32-rmt.yaml

+# Copyright (c) 2025 Joel Guittet (joelguittet@gmail.com)
+# SPDX-License-Identifier: Apache-2.0
+
+description: ESP32 RMT


Add a title, spell out the acronym according to the guidelines, and consider adding an actual description :) (bonus point for including an example of a dts snippet as well)

kartben · 2025-12-23T07:07:07Z

drivers/misc/espressif_rmt/rmt_common.c

+    int channel_id = chan->channel_id;
+    uint32_t periph_src_clk_hz = 0;
+    bool clock_selection_conflict = false;
+    // check if we need to update the group clock source, group clock source is shared by all channels


/* comments please

kartben · 2025-12-23T07:07:37Z

drivers/misc/espressif_rmt/Kconfig

+if ESPRESSIF_RMT
+
+config ESPRESSIF_RMT_INIT_PRIORITY
+	int "Espressir RMT init priority"


fabiobaltieri · 2025-12-23T09:28:52Z

The support file should probably be in the esp hal, unless you want to rewrite them to comply with the upstream coding style, apis etc, then the upstream code should be a driver implementing the led_strip apis.

joelguittet · 2025-12-23T09:46:52Z

@kartben thanks for the first comments. I basically agree with all of them and will update the code, but I should have explained a bit more: it's actually ported from esp-idf as is to permit Espressif and particularly @sylvioalves to provide the first feedbacks, we may consider as a draft PR probably for the moment. Support of RMT is also something asked several from community here so at least there is a first version people can cherry-pick.

@fabiobaltieri There will be an additional stuff for support of DMA and this need to use DMA APIs from Zephyr of course, so my guess is that it is probably better to have it in Zephyr. It's not a problem for me to update so that it follow Zephyr style. Basically the driver is based on esp-idf v5.1.6, which is already different from the latest esp-idf v6, so keeping in Zephyr is good I think (I have no interest to keep esp-idf style for the driver - and only the driver of course, hal is hal, driver is in zephyr !)
Also for the last part of your comment, maybe a I'm wrong and please in this case you can correct me, but just to clarify the sample: it's also retrieved from esp-idf and copied 95% as is. I'm not sure it's interesting to use led_strip APIs here for such purpose: the goal is just to show how to use RMT APIs. LED strip here is just an excuse. Later maybe some people will create a led strip driver for Espressif based on RMT driver, providing one more led strip driver in Zephyr :-)

fabiobaltieri · 2025-12-23T10:02:47Z

Sure it's fair to have it in misc if you are willing to put to work down to fix it up, problem though is that if it gets updated in idf it'll be impossible to track the changes. Anyway, your call on that.

For the rest, yeah prob fair to have it in misc to be used without a specific behavior but then I don't think we should merge a sample that makes it do a functionality that we have a subsystem for if it does not use the subsystem apis. But at that point it should be pretty straightforward to implement a led_strip driver on top of it.

wmrsouza · 2025-12-23T12:42:20Z

@joelguittet my 2 cents:

rmt probably should define a new device driver api (but I'm not sure about that), despite the fact it is near to uart, spi and i2s behavior (they are all communications buses)
after defining the driver api for the rmt_esp32 peripheral, you should fill the gaps with hal_espressif calls
for reference:
rmt could perfectly be a back end for led_strip (as spi, uart and i2s), but I think this should be a new PR dependent on this one

wmrsouza · 2025-12-23T12:50:21Z

drivers/misc/espressif_rmt/Kconfig

+menuconfig ESPRESSIF_RMT
+	bool "Espressif RMT driver"
+	help
+	  Enable config options for Espressif RMT driver.


My sugestion:

config RMT_ESP32 bool "ESP32 RMT driver" default y depends on DT_HAS_ESPRESSIF_ESP32_RMT_ENABLED select DMA if DT_HAS_ESPRESSIF_ESP32_GDMA_ENABLED help Enables the ESP32 Remote Control Transceiver driver.

My comment on this proposition:

Renaming the name of the config: ok for me.

Why defaulting to y ? We may want to just not include it in general. => EDIT: with default y then we just need to activate rmt in the dts of course :-) I add this one.

select DMA should be added later when I will integrate DMA API for sure. However, this is only for ESP32S3 .so an additional condition should be added I guess.

@wmrsouza For renaming the config, I cannot. The CI is checking for proper order and consistency of drivers in misc directory. I should be espressif_rmt top have vendor first, and then ESPRESSIF_RMT for the config.

joelguittet · 2025-12-23T21:56:59Z

@fabiobaltieri I see there is a led_strip sample. I can imagine to not commit the sample I have done in this branch, and instead open another pull-request to add a rmt based led-strip driver. So that the current led_strip sample can be reused to demonstrate rmt usage. What do you think?

@wmrsouza your inputs are much appreciated! But I'm not sure to understand your 2 first bullet points. Today I have just followed the esp-idf APIs. RMT is specific to Espressif in any case so I don't see any interest to define a general driver API for that, isn't it ?
By the way, actually there is one thing that maybe do not follow the best practise (you will tell me @kartben please!): the APIs have no "struct device". It will not be used (at least for the moment), so I don't see any interest for this one. Tell me if I'm wrong.
You join the conversation with Fabio just above, a new pull-request for a led strip driver rmt based will be nice yes!

wmrsouza · 2025-12-24T00:54:27Z

@joelguittet I think you should follow Zephyr's driver model:

driver api even if rmt is restricted to Espressif (config, read, write, ...)
struct device for each peripheral instance even if there is only one

in general way you should start with something like this:

#define ESP32_RMT_INIT(idx)                                                             \
                                                                                        \
    PINCTRL_DT_INST_DEFINE(idx);                                                        \
                                                                                        \
    static const DRAM_ATTR struct rmt_esp32_config rmt_esp32_cfg_##idx = {              \
        .hal =  { .dev = (rmt_dev_t *)DT_INST_REG_ADDR(idx),},                          \
        .pcfg = PINCTRL_DT_INST_DEV_CONFIG_GET(idx),                                    \
        .clock_subsys = (clock_control_subsys_t)DT_INST_CLOCKS_CELL(idx, offset),       \
        .irq_source = DT_INST_IRQ_BY_IDX(idx, 0, irq),                                  \
        .irq_priority = DT_INST_IRQ_BY_IDX(idx, 0, priority),                           \
        .irq_flags = DT_INST_IRQ_BY_IDX(idx, 0, flags),                                 \
        ESP_RMT_DMA_INIT(idx),                                                          \
        .property_0 = DT_INST_PROP(idx, property_0),                                    \
        .property_1 = DT_INST_ENUM_IDX(idx, property_1),                                \
...                                                                                     \
        .property_n = DT_INST_ENUM_IDX(idx, property_n),                                \
};                                                                                      \
                                                                                        \
    static struct rmt_esp32_data rmt_esp32_data_##idx = {                               \
        .rx_config = {0},                                                               \
        .tx_config = {0},                                                               \
...                                                                                     \
        },                                                                              \
    };                                                                                  \
                                                                                        \
    DEVICE_DT_INST_DEFINE(idx, rmt_esp32_init, NULL, &rmt_esp32_data_##idx,             \
                          &rmt_esp32_cfg_##idx, POST_KERNEL,                            \
                          CONFIG_RMT_INIT_PRIORITY, &rmt_esp32_api);

DT_INST_FOREACH_STATUS_OKAY(ESP32_RMT_INIT);

joelguittet · 2026-02-14T23:00:20Z

@sylvioalves @wmrsouza for your information I created zephyrproject-rtos/hal_espressif#516 and #104097 because I will be blocked here with the Doxygen Coverage Delta Check pipeline and the comments on the new pinctrl definitions. If these PR get merged then I will be able to update here to fix the pipeline.

joelguittet · 2026-02-25T22:21:52Z

@sylvioalves after rebasing I have again a twister issue here regarding to esp32c6 ulp core and function ulp_lp_core_sw_intr_trigger. I don't think it's currently cover by one of your opened PR so bring this to your attention.

sylvioalves · 2026-02-26T13:12:29Z

@sylvioalves after rebasing I have again a twister issue here regarding to esp32c6 ulp core and function ulp_lp_core_sw_intr_trigger. I don't think it's currently cover by one of your opened PR so bring this to your attention.

Please rebase.

joelguittet · 2026-02-26T20:56:02Z

@sylvioalves after rebasing I have again a twister issue here regarding to esp32c6 ulp core and function ulp_lp_core_sw_intr_trigger. I don't think it's currently cover by one of your opened PR so bring this to your attention.

Please rebase.

Re-rebased, passing. Thanks.
Ready for next steps of the review, you opened some points in the led-strip PR but as indicated there I would prefer to continue here for pure RMT support. Some points can be closed too.
Don't hesitate.

sylvioalves · 2026-02-27T18:35:56Z

drivers/misc/espressif_rmt/rmt.c

+/* Retrieve DMA device if defined, else default to NULL */
+#define ESPRESSIF_RMT_DT_INST_DMA_CTLR(idx)                                         \
+	COND_CODE_1(DT_INST_NODE_HAS_PROP(idx, dmas),                                   \
+		(DEVICE_DT_GET(DT_INST_DMAS_CTLR(0))),                                      \


DMa is hardcoded with 0. Use idx instead:
(DEVICE_DT_GET(DT_INST_DMAS_CTLR(idx))),

sylvioalves · 2026-02-27T18:36:34Z

drivers/misc/espressif_rmt/rmt.c

+		(ESPRESSIF_RMT_DMA_CHANNEL_UNDEFINED))
+
+#define ESPRESSIF_RMT_INIT(idx)                                                     \
+	PINCTRL_DT_DEFINE(DT_NODELABEL(rmt));                                           \


+ PINCTRL_DT_INST_DEFINE(idx); \ + static const struct espressif_rmt_config espressif_rmt_cfg_##idx = { \ + .pcfg = PINCTRL_DT_INST_DEV_CONFIG_GET(idx), \ .dma_dev = ESPRESSIF_RMT_DT_INST_DMA_CTLR(idx), \ - .tx_dma_channel = ESPRESSIF_RMT_DT_INST_DMA_CELL(0, tx, channel), \ - .rx_dma_channel = ESPRESSIF_RMT_DT_INST_DMA_CELL(0, rx, channel), \ + .tx_dma_channel = ESPRESSIF_RMT_DT_INST_DMA_CELL(idx, tx, channel), \ + .rx_dma_channel = ESPRESSIF_RMT_DT_INST_DMA_CELL(idx, rx, channel), \

sylvioalves · 2026-02-27T18:37:36Z

drivers/misc/espressif_rmt/rmt.c

+		},                                                                          \
+	};                                                                              \
+	DEVICE_DT_INST_DEFINE(idx, rmt_init, NULL, &espressif_rmt_data_##idx,           \
+		&espressif_rmt_cfg_##idx, PRE_KERNEL_1, CONFIG_ESPRESSIF_RMT_INIT_PRIORITY, \


I guess it should be POST_KERNEL?

I copied on other ESP32 drivers, but okay to change to POST_KERNEL. Done.

sylvioalves · 2026-02-27T18:39:11Z

drivers/misc/espressif_rmt/Kconfig

+
+config ESPRESSIF_RMT_INIT_PRIORITY
+	int "ESP32 RMT driver init priority"
+	default 90


default 50

Probably better with config KERNEL_INIT_PRIORITY_DEVICE (which default to 50).

sylvioalves · 2026-02-27T18:41:41Z

drivers/misc/espressif_rmt/rmt.c

+{
+	const struct espressif_rmt_config *config = dev->config;
+	int rc;
+


Missing common driver init checks:

if (!device_is_ready(config->clock_dev)) { LOG_ERR("Clock device not ready"); return -ENODEV; } #if SOC_RMT_SUPPORT_DMA if (config->dma_dev && !device_is_ready(config->dma_dev)) { LOG_ERR("DMA device not ready"); return -ENODEV; } #endif

sylvioalves · 2026-02-27T20:34:16Z

include/zephyr/drivers/misc/espressif_rmt/rmt_common.h

+	/** Carrier wave frequency, in Hz, 0 means disabling the carrier */
+	uint32_t frequency_hz;
+	/** Carrier wave duty cycle (0~100%) */
+	float duty_cycle;


I think having this as float isn't helpful due to FPU and SoC dependency. I suggest modifying to:
uint16_t duty_cycle;
uint32_t high_ticks = total_ticks * config->duty_cycle / 1000;
or if you follow Zephyr's PWM API:

+ uint32_t period_ticks; + uint32_t pulse_ticks;

Done for the first proposal. Comment describing the duty_cycle variable updated to indicate the unit is 0.1%

sylvioalves · 2026-02-27T20:36:44Z

Would you also add a test case? tests/drivers/misc/espressif_rmt/ with loopback TX→RX

sylvioalves · 2026-02-27T20:38:31Z

dts/bindings/misc/espressif,esp32-rmt.yaml

+    pinctrl is used to configure RMT channels and GPIO to be used.
+    When using ESP32 or ESP32S2 series, each RMT channel should be used once (eg. RMT_OUT0_GPIOxx
+    and RMT_IN0_GPIOxx can't be used at the same time, etc.). An error is displayed when trying to
+    create channels whith such configuration.


create channels with such configuration

Good catch! Fixed.

sylvioalves · 2026-02-27T20:39:13Z

drivers/misc/espressif_rmt/Kconfig

+
+config ESPRESSIF_RMT_ISR_IRAM_SAFE
+	bool "RMT ISR IRAM-Safe"
+	default n


default n can go as it is default.

Correct, removed.

sylvioalves · 2026-02-27T20:39:17Z

drivers/misc/espressif_rmt/Kconfig

+
+config ESPRESSIF_RMT_PM
+	bool "Support for power management"
+	default n


Removed too.

sylvioalves · 2026-02-27T20:41:06Z

drivers/misc/espressif_rmt/rmt_tx.c

+#include <zephyr/drivers/dma/dma_esp32.h>
+#include <zephyr/drivers/pinctrl.h>
+#include <zephyr/drivers/pinctrl/pinctrl_esp32_common.h>
+#include <zephyr/logging/log.h>


would you move the LOG module not to be between #includes? same on rmt_tx.c file.

sylvioalves · 2026-02-27T20:43:00Z

drivers/misc/espressif_rmt/rmt.c

+#error "DMA peripheral is not enabled!"
+#endif
+
+LOG_MODULE_REGISTER(espressif_rmt, CONFIG_ESPRESSIF_RMT_LOG_LEVEL);


This is correct as it is registering the RMT logging.
But in all other .c files, it should only DECLARE it, not register again. So please update other .c files to use LOG_MODULE_DECLARE(espressif_rmt, CONFIG_ESPRESSIF_RMT_LOG_LEVEL); instead.

Correct, fixed.

sylvioalves · 2026-02-27T20:44:03Z

drivers/misc/espressif_rmt/rmt_rx.c

+	 * APB clock no matter what the clock source is used by the RMT channel as the "core"
+	 * clock
+	 */
+#if CONFIG_IDF_TARGET_ESP32 || CONFIG_IDF_TARGET_ESP32S2


#if defined(CONFIG_SOC_SERIES_ESP32) || defined(CONFIG_SOC_SERIES_ESP32S2)

sylvioalves · 2026-02-27T20:45:00Z

drivers/misc/espressif_rmt/rmt_tx.c

+			return;
+		}
+		/* delay a while, wait for DMA data going to RMT memory block */
+		esp_rom_delay_us(1);


Use Zephyr API instead: k_busy_wait(1);.

Fixed. Note: you have a few of them in i2c and sdhc driver + hw_init. Let me know if you would like a PR for them (if relevant, which I'm not sure, but maybe preferable to change using k_sleep with K_USEC).

sylvioalves · 2026-02-27T20:45:26Z

drivers/misc/espressif_rmt/rmt_tx.c

+	if (t->loop_count != 0) {
+		if (unlikely(encoded_symbols > tx_chan->base.mem_block_num
+			* SOC_RMT_MEM_WORDS_PER_CHANNEL)) {
+			ESP_DRAM_LOGE("rmt",


sylvioalves · 2026-02-27T20:46:07Z

drivers/misc/espressif_rmt/rmt_rx.c

+		 * data and reset the pointer
+		 */
+		rmt_ll_clear_interrupt_status(hal->regs, RMT_LL_EVENT_RX_ERROR(channel_id));
+		ESP_DRAM_LOGE("rmt", "hw buffer too small, received symbols truncated");


LOG_ERR. Check all files please.

joelguittet · 2026-03-01T20:23:14Z

Would you also add a test case? tests/drivers/misc/espressif_rmt/ with loopback TX→RX

Examples in samples/drivers/misc/espressif_rmt directory implement a loopback. This will mean duplicate a sample to go in the tests ?

The Espressif RMT driver is created from the ESP-IDF version. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

The RMT peripheral is added to the existing relevant devices. A DTS bindings is created to support this peripheral. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Adding RMT pinctrl for all relevant ESP32 devices. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Indicate rmt support for all relevant Espressif boards. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Add definition for default rmt pinctrl on all relevant boards. GPIO12 and GPIO13 are used by default. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Adding this application to test espressif_rmt driver using bytes encoder. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Adding this application to test espressif_rmt driver using simple encoder. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Update hal to integrate RMT support. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

sonarqubecloud · 2026-03-18T17:26:30Z

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
24.9% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added area: Devicetree Bindings platform: ESP32 Espressif ESP32 area: Samples Samples area: Xtensa Xtensa Architecture area: Boards/SoCs labels Dec 22, 2025

zephyrbot requested review from JarmouniA, LucasTambor, andyross, ceolin, dcpleung, kartben, marekmatej, nashif, raffarost, sylvioalves, uLipe and wmrsouza December 22, 2025 23:48

zephyrbot assigned sylvioalves Dec 22, 2025

joelguittet mentioned this pull request Dec 22, 2025

ESP32/ESP32S3 RMT #72546

Open

kartben requested changes Dec 23, 2025

View reviewed changes

joelguittet marked this pull request as draft December 23, 2025 09:59

wmrsouza reviewed Dec 23, 2025

View reviewed changes

joelguittet force-pushed the feature/espressif-rmt-driver branch 2 times, most recently from b1249e5 to de36e05 Compare December 23, 2025 23:38

sylvioalves reviewed Feb 27, 2026

View reviewed changes

joelguittet added 8 commits March 18, 2026 17:03

drivers: add support for espressif rmt peripheral

e9840ea

The Espressif RMT driver is created from the ESP-IDF version. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

device tree: add rmt peripheral to esp32 socs

cb7ff88

The RMT peripheral is added to the existing relevant devices. A DTS bindings is created to support this peripheral. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

dt-bindings: pinctrl: add esp32 rmt pins definition

738002d

Adding RMT pinctrl for all relevant ESP32 devices. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

boards: espressif: indicate rmt support for all relevant boards

8a5df3a

Indicate rmt support for all relevant Espressif boards. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

boards: espressif: add rmt default pinctrl for all relevant boards

e0dae01

Add definition for default rmt pinctrl on all relevant boards. GPIO12 and GPIO13 are used by default. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

samples: drivers: add espressif rmt bytes encoder application

ff4bd21

Adding this application to test espressif_rmt driver using bytes encoder. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

samples: drivers: add espressif rmt simple encoder application

fe6013f

Adding this application to test espressif_rmt driver using simple encoder. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

manifest: esp32: update hal_espressif

c6cdac0

Update hal to integrate RMT support. Signed-off-by: Joel Guittet <joelguittet@gmail.com>

Conversation

joelguittet commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabiobaltieri commented Dec 23, 2025

Uh oh!

joelguittet commented Dec 23, 2025

Uh oh!

fabiobaltieri commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wmrsouza commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wmrsouza Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joelguittet Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joelguittet commented Dec 23, 2025

Uh oh!

wmrsouza commented Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joelguittet commented Feb 14, 2026

Uh oh!

joelguittet commented Feb 25, 2026

Uh oh!

sylvioalves commented Feb 26, 2026

Uh oh!

joelguittet commented Feb 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sylvioalves commented Feb 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

joelguittet commented Dec 22, 2025 •

edited

Loading

fabiobaltieri commented Dec 23, 2025 •

edited

Loading

wmrsouza commented Dec 23, 2025 •

edited

Loading

wmrsouza Dec 23, 2025 •

edited

Loading

joelguittet Dec 23, 2025 •

edited

Loading

wmrsouza commented Dec 24, 2025 •

edited

Loading

joelguittet Mar 1, 2026 •

edited

Loading