Closed
Description
I haven't investigated this very far yet, but I noticed that the sdkconfig files set CONFIG_FREERTOS_UNICORE=y. I tried modifying this in order to pin a (pure c) task on core 1 but experienced some sort of crash. Ultimately it would be great to see the dual core feature of the ESP32 utilized, if only to allow core 0 to be in charge of the wireless communication stack while MicroPython runs on core 1.
Here's my output recorded using the ESP IDF monitor.
WARNING: esp-idf git submodule components/esp32/lib may be out of date. Run 'git submodule update' in IDF_PATH dir to update.
Toolchain path: /Users/me/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a
Compiler version: 5.2.0
Python requirements from /Users/me/esp/esp-idf/requirements.txt are satisfied.
MONITOR
--- idf_monitor on /dev/cu.usbserial-1410 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
I (411) cpu_start: Pro cpu up.
I (411) cpu_start: Application information:
I (411) cpu_start: Compile time: 22:45:38
I (413) cpu_start: Compile date: Mar 15 2019
I (418) cpu_start: ESP-IDF: v3.3-beta1-268-g5c88c5996
I (425) cpu_start: Starting app cpu, entry point is 0x40082848
0x40082848: _realloc_r at /Users/me/esp/esp-idf/components/newlib/syscalls.c:47
I (0) cpu_start: App cpu up.
I (435) heap_init: Initializing. RAM available for dynamic allocation:
I (442) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (448) heap_init: At 3FFB9E90 len 00026170 (152 KiB): DRAM
I (454) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (461) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (467) heap_init: At 40092944 len 0000D6BC (53 KiB): IRAM
I (473) cpu_start: Pro cpu start user code
I (44) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
/Users/me/partial_directory_name_cut_off_by_crash(?)
No rush. But I think this would be a very nice feature to add.