Issue still exists. My current workaround is to add a delay on my Python server before sending any messages since the first message gets dropped on the ESP32.

The mcp2515 has an operating range of 2.7 to 5.5V. You shouldn’t have an issue operating at 3.3V unless there’s something I’m missing.

I’d highly recommend doing this inside a docker container. I just upgraded a large code base from 4.4 to 5.1 by using a devcontainer that was set up for esp-idf 5.1. Going back and forth between different IDF versions can be a big pain because of all the tool chain and python dependency issues.

Not every microcontroller needs WiFi and/or ble. This looks like an excellent competitor to STM’s f7 series micros. Can’t wait to start using the P4 in my designs! I’m glad you all finally have another micro with an embedded Ethernet MAC.

Any idea on approximate-ish, sorta release date?

This looks really cool! Thanks for sharing, I’ll try it out.

Here’s an example of using the rmt peripheral as an extra UART. Note that I’ve never used this library. https://github.com/naffej/esp32-rmt-uar ... rmt_uart.c

Thanks for creating and maintaining this so well. Going to use it in my next project.

I know this is well after your original post, but if you're still having issues, let me know and I'll share a copy of my cmakelists that generates some code successfully.

You should just be able to move your add_dependencies outside of the CMAKE_EARLY_EXPANSION check and it should work.

@mikemoy, mainly to reduce vias for some high-frequency rmii signals.

@ESP_Sprite, thanks for the tip, that is an excellent idea.

Is there any issue with deleting pins 17-22 from the footprint and routing traces under them (protected by soldermaks, of course)? See attached screenshot.