If setting the frequency to a value used already by an existing timer, this
timer will be used. But still, the duty cycle for that channel may have to
be changed.
Fixes issues #8306 and #8345.
If MicroPython threads are enabled, loops waiting for an incoming event
should release the GIL and suspend, allowing other tasks to run while they
wait.
Prior to this commit, the problem can easily be observed by running a
thread that is both busy and regularly releases the GIL (for example a loop
doing something then sleeping a few ms after each iteration). When the
main task is at the REPL, the thread is significantly stalled. If the main
task is manually made to release the GIL (for example, by calling
utime.sleep_ms(500)) the other thread can be seen immediately working at
the expected speed again.
Additionally, there are various instances in where blocking functions run
MICROPY_EVENT_POLL_HOOK in a loop while they wait for a certain event/
condition. For example the uselect methods poll objects to determine
whether data is available, but uses 100% of CPU while it does, constantly
calling MICROPY_EVENT_POLL_HOOK in the process.
The MICROPY_EVENT_POLL_HOOK macro is only ever used in waiting loops, where
(if threads are enabled) it makes sense to yield for a single tick so that
these loops do not consume all CPU cycles but instead other threads may
execute. (In fact, the thing these loops wait for may even indirectly or
directly depend on another task being able to run.)
This change moves the sleep that was inside the REPL input function to
inside the MICROPY_EVENT_POLL_HOOK macro, where the GIL is already being
released, solving both the blocking REPL issue and the 100% CPU use issue
at the same time.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
Prior to this fix, if the ADC atten value was not explicitly given then
adc1_config_channel_atten() would never be called.
Fixes issue #8275.
Signed-off-by: Damien George <damien@micropython.org>
The inclusion of `umachine` in the list of built-in modules is now done
centrally in py/objmodule.c. Enabling MICROPY_PY_MACHINE will include this
module.
As part of this, all ports now have `umachine` as the core module name
(previously some had only `machine` as the name).
Signed-off-by: Damien George <damien@micropython.org>
This change allows the same heap allocation rules to be used when using
malloc regardless if the board has SPRAM or normal RAM.
Integrating with the esp32-camera for example requires that ESP32 SPRAM be
allocatable using the esp-idf capabilities aware allocation functions. In
the case of esp32-camera it's for the framebuffer.
Detect when CONFIG_SPIRAM_USE_MALLOC is in use and use the standard
automatic configuration of leaving 1/2 of the SPRAM available to other
FreeRTOS tasks.
For example the ESP32-C3 has 2 TX channels and 2 RX channels in total, and
in this case channel 1 must be the default for bitstream.
Signed-off-by: Damien George <damien@micropython.org>
This follows up on #5489, where we changed the esp32 core pinning to core 0
in order to work around an issue with IDF < 4.2.0. Now that IDF > 4.2.0 is
available, we allow pinning back to core 1, which eliminates some
problematic callback latency with WiFi enabled.
NimBLE is also pinned to core 1 - the same core as MicroPython - when using
IDF >=4.2.
Rework the ADC implementation to follow the improved ADC/ADCBlock API.
This adds support for calibrated voltage readings and the ADC2 block. The
ADC API is backwards compatible with what it was before this change.
Resolves#6219.
The bit-bang implementation was replaced with the RMT implementation in
599b61c086. This commit brings back that
bit-bang code, and allows it to be selected via the new static method:
esp32.RMT.bitstream_channel(None)
The bit-bang implementation may be useful if the RMT needs to be used for
something else, or if bit-banging is more stable in certain applications.
Signed-off-by: Damien George <damien@micropython.org>
MicroPython currently runs on core 0 of the esp32. Calling
rmt_driver_install will mean that the RMT interrupt handler is also
serviced on core 0. This can lead to glitches in the RMT output if
WiFi is enabled (for esp32.RMT and machine.bitstream).
This patch calls rmt_driver_install on core 1, ensuring that the RMT
interrupt handler is serviced on core 1. This prevents glitches.
Fixes issue #8161.
Signed-off-by: Damien George <damien@micropython.org>
This board has only 2MiB of flash so the build needs to be reduced in size
to fit. Commit 549448e8bb made all boards
build with -O2 by default (for performance) so this overrides that default.
Signed-off-by: Damien George <damien@micropython.org>
After changing the bitstream implementation to use the RMT driver in
commit 72d86158121e32bbabaeade08f449d507bf40f9a
("esp32/machine_bitstream.c: Replace with RMT-based driver."), using
multiple `Neopixel` instances shows signal duplication between the
instances (i.e. a `write()` on one instance is written to all instances).
On invocation, the rmt driver configures the GPIO matrix to route the
output signal to the respective GPIO pin. When called for a different
`NeoPixel` instance using a different pin, the new route is established,
but the old route still exists. Now, the RMT output signal is sent to both
pins.
Fix this by setting the standard GPIO output function for the current pin
after uninstalling the RMT driver.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Save and restore the same duty cycle when the frequency (or frequency
resolution) is changed. This allows a smooth frequency change.
Also update the esp32 PWM quickref to be clearer.
If MICROPY_PY_SYS_PATH_ARGV_DEFAULTS is enabled (which it is by default)
then sys.path and sys.argv will be initialised and populated with default
values. This keeps all bare-metal ports aligned.
Signed-off-by: Damien George <damien@micropython.org>
Frozen modules will be searched preferentially, but gives the user the
ability to override this behavior.
This matches the previous behavior where "" was implicitly the frozen
search path, but the frozen list was checked before the filesystem.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Default SPI pins are now correctly assigned by machine_hw_spi.c even for S2
and S3. mpconfigboard.h files define defaults with flipped SPI(1) and
SPI(2) to workaround a bug in machine_hw_spi.c - the bug is fixed.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Use IO_MUX pins as defined by ESP IDF in soc/esp32/include/soc/spi_pins.h
ESP32S2 and S3 don't have IO_MUX pins for SPI3, GPIO matrix is always used.
Choose suitable defaults for S2 and S3.
ESP32C3 does not have SPI3 at all. Don't define pin mappings for it.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Use IO_MUX pins as defined by ESP IDF in soc/esp32*/include/soc/spi_pins.h
Alternatively use now deprecated HSPI_IOMUX_PIN_NUM_xxx
(or FSPI_IOMUX_PIN_NUM_xxx for ESP32S2) for compatibility with IDF 4.2
and older.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
The index of machine_hw_spi_obj and machine_hw_spi_default_pins arrays is
assigned to 0 for ARG_id==HSPI_HOST and 1 for another SPI. On ESP32S2 and
S3 HSPI_HOST=2 so the first set (idx=0) of default pins is used for
SPI(id=2) aka HSPI/SPI3 and the second set (idx=1) for SPI(id=1) aka
FSPI/SPI2. This makes a misleading mess in MICROPY_HW_SPIxxxx definitions
and it is also in contradiction to the comments around the definitions.
Change the test of ARG_id to fix the order of machine_hw_spi_default_pins.
This change might require adjusting MICROPY_HW_SPIxxxx definitions in
mpconfigboard.h of S2/S3 based boards.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
