Currently ESP_PYTHON is used in the install.sh script, but it's
overwritten in detect_python.sh. This allows to explicitly specify
python binary, which should be used to create venv.
$ ESP_PYTHON=/usr/bin/python3.7 ./install.{sh,fish}
$ ESP_PYTHON=/usr/bin/python3.7 ./export.{sh,fish}
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
feat(mcpwm): Allow for pull up/down to be configurable on generators (GitHub PR)
Closes IDFGH-10647 and IDFGH-10646
See merge request espressif/esp-idf!24825
If CONFIG_SPIRAM_USE_MALLOC is enabled, and cache is disabled when GPIO ISR is triggered,
it would lead to Guru Meditation Error due to "Cache disabled but cached memory region accessed".
Closes https://github.com/espressif/esp-idf/issues/11876
1: add the CONFIG_BT_BQB_ENABLED for some functions of bqb test.
2: add bqb_rfc_send_msc_cmd function to send rfcomm msc command with
only address arg input.
* improved setup/teardown to not put shared event system into
inconsistent state
* reduced timing-dependency of several tests by using
a semaphore instead of waiting for a guessed timeout
* Deactivated WDT (both Interrupt WDT, Task WDT) for QEMU tests
* Ignore esp_timer-based test for QEMU, CPU timing is different
on ESP32 simulation in QEMU
Application partition size was not correctly declared per secure
boot alignment requirements. This was causing build failure when
example was built with secure boot enabled.
Now the soc interrupts definitions are scattered around in the esp-idf
which are out of sync. Put interrupts definitions in soc/periph_defs.h
(!ESP32) or soc/soc.h(ESP32) together in soc/interrupts.h.
idf.py spawns gdb process within a thread and uses Thread.join() to wait
for the gdb process to finish. As CTRL+C(SIGINT) is used by gdb to interrupt the
running program, we catch the SIGINT while waiting on the gdb to finish,
and try Thread.join() again.
With cpython's commit
commit a22be4943c119fecf5433d999227ff78fc2e5741
Author: Victor Stinner <vstinner@python.org>
Date: Mon Sep 27 14:20:31 2021 +0200
bpo-45274: Fix Thread._wait_for_tstate_lock() race condition (GH-28532)
this logic doesn't work anymore, because cpython internally marks the
thread as stopped when join() is interrupted with an exception. IMHO
this is broken in cpython and there is a bug report about this
https://github.com/python/cpython/issues/90882. Problem is that
waiting on a thread to finish is based on acquiring a lock. Meaning
join() is waiting on _tstate_lock. If this wait is interrupted, the
above referenced commit adds a logic that checks if the lock is help,
meaning the thread is done and marks the thread as stopped. But there is
no way to tell if the lock was acquired by us running join() or if it's
held by someone else e.g. still by the thread bootstrap code. Meaning
the thread is still running.
I may be missing something, but I don't see any reason why to spawn gdb
process within a thread. This change removes the thread and spawns gdb
directly. Instead waiting on a thread, we wait on the process to finish,
replacing join() with wait() and avoiding this problem.
Closes https://github.com/espressif/esp-idf/issues/11871
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
