ESP32 port now uses CMake
Re: ESP32 port now uses CMake
I see that rp2 port is going on on this topic. You saw it probably. Maybe there is some info to grab there...
https://github.com/micropython/micropython/pull/6960
https://github.com/micropython/micropython/pull/6960
Re: ESP32 port now uses CMake
Not really a esp32 specific question,
How does this affect making native modules? Was thing I making a few based off some C libraries I want to use and don't know if I should stay on my version I am currently working with for another project or start work in a new copy of micropython now that it uses CMake?
Asking because all the Natmod examples still use a Makefile and not anything relating to CMake.
How does this affect making native modules? Was thing I making a few based off some C libraries I want to use and don't know if I should stay on my version I am currently working with for another project or start work in a new copy of micropython now that it uses CMake?
Asking because all the Natmod examples still use a Makefile and not anything relating to CMake.
Re: ESP32 port now uses CMake
I was able to get the approach used by the rp2 to work on esp32 so will adapt my pull request to share the same approach.
The base changes will go in on their pull request: https://github.com/micropython/micropython/pull/6960
Then I'll adjust mine(https://github.com/micropython/micropython/pull/6956) to use the common file but called from the esp32 port make file.
The base changes will go in on their pull request: https://github.com/micropython/micropython/pull/6960
Then I'll adjust mine(https://github.com/micropython/micropython/pull/6956) to use the common file but called from the esp32 port make file.
Re: ESP32 port now uses CMake
I had some trouble getting the c++ example to build but I just finished pushing my code that supports user modules on esp32 using the rp2 port approach.
https://github.com/micropython/micropython/pull/6956
Caveat: I changed how the qstr.i.last file is generated and while it works I have no idea if its a safe change or not.
I'm building in windows using docker for windows in the windows subsystem for linux.
I run this command from the clone of micropython which puts the current working directory into /src in the docker container.
Then within the docker container I change to the ports/esp32 directory and run the build command:
For example:
Then I have esptool installed in windows and use it to write the firmware:
https://github.com/micropython/micropython/pull/6956
Caveat: I changed how the qstr.i.last file is generated and while it works I have no idea if its a safe change or not.
I'm building in windows using docker for windows in the windows subsystem for linux.
I run this command from the clone of micropython which puts the current working directory into /src in the docker container.
Code: Select all
winpty docker run -i -t -v /$(pwd):/src espressif/idf:release-v4.3 bash
Code: Select all
make USER_C_MODULES=/src/examples/usercmodule
Code: Select all
root@0219af9b1ad7:/src/ports/esp32# rm -rf build-GENERIC/ && make USER_C_MODULES=/src/examples/usercmodule
...
MPY websocket_helper.py
GEN /src/ports/esp32/build-GENERIC/frozen_content.c
[1300/1300] Generating binary image from built executable
esptool.py v3.1-dev
Merged 1 ELF section
Generated /src/ports/esp32/build-GENERIC/micropython.bin
Project build complete. To flash, run this command:
/opt/esp/python_env/idf4.3_py3.6_env/bin/python ../../../opt/esp/idf/components/esptool_py/esptool/esptool.py -p (
PORT) -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size
detect --flash_freq 40m 0x1000 build-GENERIC/bootloader/bootloader.bin 0x8000 build-GENERIC/partition_table/partit
ion-table.bin 0x10000 build-GENERIC/micropython.bin
or run 'idf.py -p (PORT) flash'
bootloader 22800
partitions 3072
application 1399408
total 1464944
Code: Select all
esptool.py --chip esp32 --port COM5 write_flash -z 0x1000 ./micropython/ports/esp32/build-GENERIC/firmware.bin
Re: ESP32 port now uses CMake
Am I correct with my guess, that it's currently not possible to include btree in a CMake build for the esp32?
I've been struggling with this for quite a while now, and I guess it might be related to this.
I've been struggling with this for quite a while now, and I guess it might be related to this.
Re: ESP32 port now uses CMake
The rp2 pull request #6960 has been merged.
My pull request #6956 works and is greatly simplified now that its using the rp2 port contributions.
If anyone has custom esp32 firmwares can you checkout the branch from my pull request and see if it works for you?
Its successfully built the usercexample's and the latest ulab.
My pull request #6956 works and is greatly simplified now that its using the rp2 port contributions.
If anyone has custom esp32 firmwares can you checkout the branch from my pull request and see if it works for you?
Its successfully built the usercexample's and the latest ulab.
Re: ESP32 port now uses CMake
Hello,
Happy to report that this was successful (however I hit one QSTR issue)...
Russ Hughes' ST7789 module built using your branch and espIDF 4.0. The display.fill() is working as expected. https://github.com/russhughes/st7789_mpy
There was one error during compilation: "MP_QSTR_mp_file undeclared here". I don't know if this error is local to the code or related to cmake. The very temporary workaround was to simply comment out the ".name = MP_QSTR_mp_file" line in mpfile.c. I need to resolve this issue however)
cmake file used:
Happy to report that this was successful (however I hit one QSTR issue)...
Russ Hughes' ST7789 module built using your branch and espIDF 4.0. The display.fill() is working as expected. https://github.com/russhughes/st7789_mpy
There was one error during compilation: "MP_QSTR_mp_file undeclared here". I don't know if this error is local to the code or related to cmake. The very temporary workaround was to simply comment out the ".name = MP_QSTR_mp_file" line in mpfile.c. I need to resolve this issue however)
cmake file used:
Code: Select all
# Create an INTERFACE library for our C module.
add_library(usermod_st7789 INTERFACE)
# Add our source files to the lib
target_sources(usermod_st7789 INTERFACE
${CMAKE_CURRENT_LIST_DIR}/st7789.c
)
# Add the current directory as an include directory.
target_include_directories(usermod_st7789 INTERFACE
${CMAKE_CURRENT_LIST_DIR}
)
target_compile_definitions(usermod_st7789 INTERFACE
MODULE_ST7789_ENABLED=1
MICROPY_PY_FILE_LIKE=1
EXPOSE_EXTRA_METHODS=1
)
# Link our INTERFACE library to the usermod target.
target_link_libraries(usermod INTERFACE usermod_st7789)
Re: ESP32 port now uses CMake
My guess is that is caused by using: #include "mpfile.c" in the st7789.c so the build system doesn't know about the QSTR's in mpfile.c. You should be able to remove the #include "mpfile.c" from st7789.c and add mpfile.c to the cmake. I did the same thing with "tjpgd565.c" but it does not have any QSTR's in it.
Re: ESP32 port now uses CMake
Russ, thank you, it was the #includes.
The fix was to #include the .h's rather than the .c's for both the dependencies and change cmake to compile all three.
michael.o, thank you again, happy to report your branch is tested with st7789_mpy on the TTGO7789 Tdisplay.
One observation, I was required to specify the cmake file when compiling, the directory containing the file was not enough.
The fix was to #include the .h's rather than the .c's for both the dependencies and change cmake to compile all three.
michael.o, thank you again, happy to report your branch is tested with st7789_mpy on the TTGO7789 Tdisplay.
One observation, I was required to specify the cmake file when compiling, the directory containing the file was not enough.
-
- Posts: 15
- Joined: Tue Feb 25, 2020 5:10 pm
Re: ESP32 port now uses CMake
As I try to make my own st7789 driver compile with cmake:
https://github.com/pypilot/micropython_ugfx
really surprised this driver does not use dma, and investigating code it appears to be very slow for a lot of other reasons as well.
https://github.com/pypilot/micropython_ugfx
really surprised this driver does not use dma, and investigating code it appears to be very slow for a lot of other reasons as well.