Skip to content

IDF-6.0 support ported from #463 - #477

Merged
vroland merged 6 commits into
mainfrom
idf-6.0-compatibility
Jun 13, 2026
Merged

IDF-6.0 support ported from #463#477
vroland merged 6 commits into
mainfrom
idf-6.0-compatibility

Conversation

@vroland

@vroland vroland commented May 11, 2026

Copy link
Copy Markdown
Owner

This PR adds the remaining ESP-IDF 6.0 support work from #463 on top of current main, after the ADC and RMT migrations from that original PR were split out and addressed separately. It updates CI to build against the stable v6.0 image, adds the remaining IDF 6 build requirements and SDK config workaround, and adapts the ESP32 I2S and ESP32-S3 LCD paths for IDF 6 API/header changes while reusing the existing rmt_compat abstraction rather than carrying over the older duplicated RMT compatibility code.

@geiseri

geiseri commented Jun 6, 2026

Copy link
Copy Markdown

I have been using this on the lilygo 4.7 esp32 version (not esp32s) and I keep getting stuck at: rmt_pulse.c#L51)
If I make this change:

diff --git a/src/output_i2s/rmt_pulse.c b/src/output_i2s/rmt_pulse.c
index 5c0d49b..dcf726c 100644
--- a/src/output_i2s/rmt_pulse.c
+++ b/src/output_i2s/rmt_pulse.c
@@ -12,8 +12,8 @@ static volatile bool rmt_tx_done = true;
 
 static void IRAM_ATTR rmt_interrupt_handler(void* arg) {
     (void)arg;
-    rmt_tx_done = true;
     rmt_compat_clear_interrupts();
+    rmt_tx_done = true;
 }
 
 void rmt_pulse_init(gpio_num_t pin) {

It doesn't lock up. I think it might be related to activity on the mcu since it happens most often during wifi station scans and transfers that last more than a second or two. That being said I am confused since all the clear does is sets a value.

@martinberlin

Copy link
Copy Markdown
Collaborator

@geiseri please raise this concerns to the Lyligo team.
epdiy has actually their own boards and we are not meant to be the Lilygo support team. So the Lilygo matters should explicitly take place over their own repositories and not here. Thanks for your understanding

@vroland

vroland commented Jun 7, 2026

Copy link
Copy Markdown
Owner Author

@geiseri Good catch, this is also a possible race condition on our boards, depending on the application. I've also fixed a few similar ones.

@vroland
vroland force-pushed the idf-6.0-compatibility branch from 85a2e00 to 1cf502e Compare June 7, 2026 11:29
@vroland

vroland commented Jun 7, 2026

Copy link
Copy Markdown
Owner Author

I still have a strange issue with this where the output is vertically stretched on with a v7 board and a ED060XC5 display, so that only 2/3 of the picture is visible. Works fine on 5.4. not sure where else to dig, maybe I'll have to check with my scope when I have the time.

@vroland
vroland marked this pull request as ready for review June 7, 2026 16:36
@vroland

vroland commented Jun 7, 2026

Copy link
Copy Markdown
Owner Author

@martinberlin Should be ready now, tested with a V7 board and V6 board. Maybe give it a quick review if you have the time :)

@vroland
vroland merged commit 8781397 into main Jun 13, 2026
22 checks passed
@vroland
vroland deleted the idf-6.0-compatibility branch June 13, 2026 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants