Add a new function to control whether held pins will retain their function
through deep-sleep.
Also document this function and explain how to use this in quickref to
retain pin configuration during deep-sleep.
The current pull=Pin.PULL_HOLD argument doesn't make a lot of sense in the
context of what it actually does vs what the ESP32 quickref document says
it does.
This commit removes PULL_HOLD and adds a new hold=True|False keyword
argument to Pin()/Pin.init(). Setting this to True will cause the ESP32 to
lock the configuration of the pin – including direction, output value,
drive strength, pull-up/-down – such that it can't be accidentally changed
and will be retained through a watchdog or internal reset.
Fixes issue #8283, and see also #8284.
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>
