Skip to content

esp32: Convert to build using cmake as an IDF component (IDF v4.0.2) #6892

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Feb 15, 2021

Conversation

dpgeorge
Copy link
Member

@dpgeorge dpgeorge commented Feb 13, 2021

This improves on #6473 and the esp32-idf41-cmake branch. It uses IDF v4.0.2 and converts the esp32 port to fully use cmake and idf.py. Traditional make support is removed. Support for all existing boards is included. WiFi and BLE work.

TODO:

  • make CI work
  • update esp32/README

@dpgeorge dpgeorge force-pushed the esp32-cmake-idf40-v2 branch 2 times, most recently from b523e86 to d7a09ea Compare February 14, 2021 06:53
@dpgeorge
Copy link
Member Author

This should be good to go in now.

These allow a port to use cmake natively instead of make.

Signed-off-by: Damien George <damien@micropython.org>
This commit adds support for building the esp32 port with cmake, and in
particular it builds MicroPython as a component within the ESP-IDF.  Using
cmake and the ESP-IDF build infrastructure makes it much easier to maintain
the port, especially with the various new ESP32 MCUs and their required
toolchains.

Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge dpgeorge force-pushed the esp32-cmake-idf40-v2 branch from d7a09ea to 509e24c Compare February 15, 2021 01:55
@jimmo
Copy link
Member

jimmo commented Feb 15, 2021

This is really great, and hugely simplifies the ESP32 port, and glad to finally remove the v3/v4 IDF split. Thanks @dpgeorge !

I'm keen to see this merged, but I guess just so that it's recorded somewhere that I can link to, my understanding is that this means that we're temporarily removing support for (wired) LAN and user c modules. In the meantime, v1.14 and v1.13 firmware will still be available with LAN support, and user c modules can be built against the v1.14 tag until a cmake-based replacement is available.

Just as a note, is py/mkrules.cmake and py/py.cmake now identical to rp2/micropy_rules.cmake and rp2/micropy_py.cmake? (Separate PR though maybe)

@dpgeorge
Copy link
Member Author

this means that we're temporarily removing support for (wired) LAN and user c modules. In the meantime, v1.14 and v1.13 firmware will still be available with LAN support, and user c modules can be built against the v1.14 tag until a cmake-based replacement is available.

Yes, correct.

Just as a note, is py/mkrules.cmake and py/py.cmake now identical to rp2/micropy_rules.cmake and rp2/micropy_py.cmake? (Separate PR though maybe)

No, they are different. The rp2 versions were actually a precursor to the ones in this PR. The aim is to migrate rp2 to use these new ones (which should improve rp2 build slightly because it'll now support ninja, and other minor improvements).

Signed-off-by: Damien George <damien@micropython.org>
This makes no functional change.  See similar commit
9aa58cf

Signed-off-by: Damien George <damien@micropython.org>
It's now replaced by cmake/idf.py.  But a convenience Makefile is still
provided with traditional targets like "all" and "deploy".

Signed-off-by: Damien George <damien@micropython.org>
IDF v3 is no longer supported with the move to cmake.

Signed-off-by: Damien George <damien@micropython.org>
BLE was enabled by default on all boards in the existing make build.

Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
@UnexpectedMaker
Copy link
Contributor

w00p! Great work @dpgeorge !

I'm keen to see this merged, but I guess just so that it's recorded somewhere that I can link to, my understanding is that this means that we're temporarily removing support for (wired) LAN and user c modules. In the meantime, v1.14 and v1.13 firmware will still be available with LAN support, and user c modules can be built against the v1.14 tag until a cmake-based replacement is available.

BTW, PPP works fine in MP with IDF4, so no idea why it's still being excluded. One of my community members built IDF4 from source (pre cmake) and enabled the PPP stuff and it using it in their project without issue.

@dpgeorge
Copy link
Member Author

BTW, PPP works fine in MP with IDF4, so no idea why it's still being excluded.

PPP is included now.

@UnexpectedMaker
Copy link
Contributor

UnexpectedMaker commented Feb 17, 2021

BTW, PPP works fine in MP with IDF4, so no idea why it's still being excluded.

PPP is included now.

Thanks @dpgeorge !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants