This commit updates the ADC to use the new driver `esp_adc/adc_oneshot.h`.
There are several errata notes about not being able to change the bit-width
of the ADCs certain chips. The only chip that can switch resolution to a
lower one is the normal ESP32. ESP32 C2 and S3 are stuck at 12 bits, while
S2 is at 13 bits.
On the S2, you can change the resolution, but it has no effect on the
resolution, rather, it prevents attenuation from working at all!
The resolution is set to the maximum possible for each SoC, with the ESP32
being the only one not throwing errors when trying to set the bit-width to
9, 10, 11 or 12 bits using `ADC.width(bits)`.
Signed-off-by: Damian Nowacki (purewack) bobimaster15@gmail.com
Support the new PHY_GENERIC device type, added in ESP-IDF v5.4.0 [1].
This PHY driver was added to ESP-IDF to support "generic"/oddball PHY
LAN chips like the JL1101, which offer no features beyond the bare
802.3 PHY standard and don't actually need a chip-specific driver (see
discussion at [2]).
[1] 0738314308
[2] https://github.com/espressif/esp-eth-drivers/pull/28
Signed-off-by: Elvis Pfutzenreuter <epxx@epxx.co>
This reduces inconsitencies between esp32 and other ports.
According to the discussion in #10817.
Signed-off-by: Ihor Nehrutsa <Ihor.Nehrutsa@gmail.com>
Some rp2 boards include WiFi, at least with the very popular Pico W and
Pico 2 W. New users frequently ask how to set up WiFi and are confused
because it's not covered in the quickref.
This commit adds the wlan section, copied and modified with notes from the
ESP32 quickref.
Signed-off-by: Matt Trentini <matt.trentini@gmail.com>
Previously ESP32-S3 SDMMC could only use fixed pin assignments, however the
ESP-IDF defaults don't match common boards. The chip also supports using
GPIO Matrix to assign any pin.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Also cross-link with the other WIZNET5K driver, to avoid confusion.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The user already has it open, and its customised for their
particular board.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Includes fixing the flashing address for newer SoCs, as reported in
discussion https://github.com/orgs/micropython/discussions/16417
Also removes some redundant or out of date information, and adds links to
the Espressif esptool docs which are quite comprehensive.
Information about ESP32_GENERIC variants is moved to the board page, as it
only applies to that board.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Removes the deprecated network.[AP|STA]_IF form from the docs.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
For ESP32C3/S2/S3 IDFv5 exposes new internal temperature API which is
different to the base ESP32, IDFv4.
Thanks to @robert-hh for cleaner code and testing sensor capability in
these devices.
See discussion #10443.
Signed-off-by: Rick Sorensen <rick.sorensen@gmail.com>
Prior to this commit, the pin defined for power would be used by the
esp_idf driver to reset the PHY. That worked, but sometimes the MDIO
configuration started before the power was fully settled, leading to an
error.
With the change in this commit, the power for the PHY is independently
enabled in network_lan.c with a 100ms delay to allow the power to settle.
A separate define for a reset pin is provided, even if the PHY reset
pin is rarely connected.
Fixes issue #14013.
Signed-off-by: robert-hh <robert@hammelrath.com>
- Update guide for extending built-in modules.
- Remove any last trace of umodule in other docs.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This adds the freq and duty_u16 keyword settings to the constructor, and
sometimes other details in the PWM section.
For mimxrt a clarification regarding the PWM invert argument was added, and
for rp2 a few words were spent on PWM output pairs of a channel/slice.
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.
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>
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.
The methods duty_u16() and duty_ns() are implemented to match the existing
docs. The duty will remain the same when the frequency is changed.
Standard ESP32 as well as S2, S3 and C3 are supported.
Thanks to @kdschlosser for the fix for rounding in resolution calculation.
Documentation is updated and examples expanded for esp32, including the
quickref and tutorial. Additional notes are added to the machine.PWM docs
regarding limitations of hardware PWM.
Anywhere a module is mentioned, use its "non-u" name for consistency.
The "import module" vs "import umodule" is something of a FAQ, and this
commit intends to help clear that up. As a first approximation MicroPython
is Python, and so imports should work the same as Python and use the same
name, to a first approximation. The u-version of a module is a detail that
can be learned later on, when the user wants to understand more and have
finer control over importing.
Existing Python code should just work, as much as it is possible to do that
within the constraints of embedded systems, and the MicroPython
documentation should match the idiomatic way to write Python code.
With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users
can consistently use "import foo" across all ports (with the exception of
the minimal ports). And the ability to override/extend via "foo.py"
continues to work well.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
