Optionally adds time() and time_ns() to the time module, as well as a
machine.RTC class that only implements the datetime() method (following the
example of the rp2 port), whose sole purpose is to provide the ability to
set the time. Also provides the basis for enabling gmtime(), localtime(),
mktime() in the time module.
The nRF52 does not have a dedicated real-time clock peripheral, but
timekeeping can be done by the same real-time counter that already powers
the time.ticks_* and related functions. For reasonable accuracy, a suitable
LFCLK source is required: The internal RC oscillator (BLUETOOTH_LFCLK_RC)
by itself is insufficient, but any of the following work fine:
- external 32kHz crystal (default)
- synthesis from HFCLK (BLUETOOTH_LFCLK_SYNTH) when HFXO (external 32MHz
crystal) is enabled
- BLUETOOTH_LFCLK_RC + periodical calibration from HFXO (automatically done
by the SoftDevice while enabled using ble.enable())
Boards can enable this by defining both configuration options
MICROPY_PY_TIME_TICKS and MICROPY_PY_TIME_TIME_TIME_NS. Additionally, they
may want to enable MICROPY_PY_TIME_GMTIME_LOCALTIME_MKTIME.
This includes a generic implementation of mp_time_localtime_get() and
mp_time_time_get() in terms of mp_hal_time_ns(), which could also be used
by other ports. In particular by the embed port, for which I originally
wrote it, noting the following:
"I'm unsure where to put modtime_mphal.h, it could also be in extmod. The
important thing is that for MICROPY_PY_TIME_INCLUDEFILE to work it must be
at the same path in both the port build (original source tree) and the
application build (micropython_embed distribution), therefore not in
ports/embed/port.
It is named .h, mismatching the corresponding ports/*/modtime.c, because it
must not be compiled separately, which naming it .c would make harder for
users of the embed port - they would need to explicitly exclude it, whereas
this way they can continue to just compile all the .c files found in the
micropython_embed distribution except those in lib."
Signed-off-by: Christian Walther <cwalther@gmx.ch>
A board that uses BLUETOOTH_LFCLK_SYNTH is expected to have a 32MHz crystal
(Do any without one exist at all? I guess not because it's required for
Bluetooth, which nRF microcontrollers are usually chosen for.), otherwise
BLUETOOTH_LFCLK_RC would be more appropriate, so start the crystal
oscillator together with LFCLK to have accurate timekeeping from the start.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
Board definitions could already define BLUETOOTH_LFCLK_RC or not to choose
whether to use the internal RC oscillator or an external 32kHz crystal as
the source for LFCLK, but that setting was only applied when the softdevice
was enabled by ble.enable(). Apply it from the start, so that the functions
of the time module always have the specified accuracy and run without
interruption when the softdevice is enabled.
Also add an option for the third LFCLK source, synthesized from the HFCLK,
by defining BLUETOOTH_LFCLK_SYNTH.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
Use the existing metal log handling mechanism instead of overriding the
metal_log, which causes build issues when logging is enabled.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Ports that use axtls cannot run the `test_tls_sites.py` test because the
sites it connects to use advanced ciphers. So skip this test on such
ports, and add a new, simpler test that doesn't require certificate
verification and works with axtls.
Signed-off-by: Damien George <damien@micropython.org>
Supporting `verify_mode` and `CERT_NONE` is required for the new `ssl.py`
code, as well as `requests` to work.
Signed-off-by: Damien George <damien@micropython.org>
This is required because the .mpy native ABI was changed by the
introduction of `mp_proto_fun_t`, see commits:
- 416465d81e
- 5e3006f117
- e2ff00e811
And three `mp_binary` functions were added to `mp_fun_table` in
commit d2276f0d41.
Signed-off-by: Damien George <damien@micropython.org>
These are needed to read/write array.array objects, which is useful in
native code to provide fast extensions that work with big arrays of data.
Signed-off-by: Damien George <damien@micropython.org>
Change provided by @ironss-iotec.
Tested with Adafruit, SEEED and MiniFig boards for non-interference.
Fixes issue #14190.
Signed-off-by: robert-hh <robert@hammelrath.com>
Using a define for MICROPY_HW_SPIFLASH_BAUDRATE in mpconfigboard.h. If not
defined the default is 24MHz.
Signed-off-by: robert-hh <robert@hammelrath.com>
For all MCUs: run the test for USB clock recovery mode fallback after USB
has been started.
For samd21: change DFLL48 config from the open loop mode variant to sync
with the XOSC32KULP. Matches better the 48MHz value.
Signed-off-by: robert-hh <robert@hammelrath.com>
Other constants such as `machine.Pin.OUT` are defined on the class that
uses them, rather than at the module level. This commit makes that the
case for WLAN network interfaces, adding IF_xxx and SEC_xxx constants.
The SEC_xxx constants are named as such to match the `security` keyword
that they are used with. And the IF_xxx constants have IF as a prefix so
they are grouped together as names.
This scheme of putting constants on the class means that only the available
features (eg security configurations) are made available as constants. It
also means that different network interfaces (eg WLAN vs LAN) can keep
their own specific constants within their class, such as PHY_xxx for LAN.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The default CYW43 WiFi AP settings were missing the security mode, leaving
the AP in open mode by default. That's changed by this commit to use
WPA/WPA2 by default.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
When defining custom USB devices, longer strings may be needed. Eventually
the memory for string descriptors can be allocated on demand, but for now
this bigger value should be reasonable.
Signed-off-by: Damien George <damien@micropython.org>
Updates a few code comments that were out of date or poorly worded. No code
changes.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Previously, constructing the singleton USBDevice object was enough to
trigger a USB disconnect on soft reset. Now it also has to be active.
The only case where this changes the behaviour is if the USBDevice object
has been constructed but never set to active (no more disconnect in this
case). Otherwise, behaviour is the same.
This change was requested by hippy on the raspberrypi forums.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
When PWM constructor was created without specifying a device or setting
both freq and duty rate, it was not tagged as used, and further calls to
get a PWM object may get the same PWM device assigned.
Fixes#13494.
Signed-off-by: robert-hh <robert@hammelrath.com>
Exceptions in pin interrupt handlers would end up crashing MicroPython with
a "FATAL: uncaught exception".
In addition, MicroPython would get stuck trying to output this error
message, or generally any print output from inside a pin interrupt handler,
through the UART after the first character, so that only "F" was visible.
The reason was a matching interrupt priority between the running pin
interrupt and the UARTE interrupt signaling completion of the output
operation. Fix that by increasing the UARTE interrupt priority.
Code taken from the stm32 port and adapted.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
Under some circumstances, after a hard reset, the low-frequency clock would
not be running. This caused time.ticks_ms() to return 0, time.sleep_ms()
to get stuck, and other misbehavior. A soft reboot would return it to a
working state.
The cause was a race condition that was hit when the bootloader would
itself turn LFCLK on, but turn it off again shortly before launching the
main application (this apparently happens with the Adafruit bootloader
from https://github.com/fanoush/ds-d6/tree/master/micropython). Stopping
the clock is an asynchronous operation and it continues running for a short
time after the stop command is given. When MicroPython checked whether to
start it by looking at the LFCLKSTAT register (nrf_clock_lf_is_running)
during that time, it would mistakenly not be started again. What
MicroPython should be looking at is not whether the clock is running at
this time, but whether a start/stop command has been given, which is
indicated by the LFCLKRUN register (nrf_clock_lf_start_task_status_get).
It is not clearly documented, but empirically LFCLKRUN is not just set when
the LFCLKSTART task is triggered, but also cleared when the LFCLKSTOP task
is triggered, which is exactly what we need.
The matter is complicated by the fact that the nRF52832 has an anomaly
(see [errata](https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_132.html?cp=5_2_1_0_1_33))
where starting the LFCLK will not work between 66µs and 138µs after it last
stopped. Apply a workaround for that. See nrfx_clock_lfclk_start() in
micropython/lib/nrfx/drivers/src/nrfx_clock.c for reference, but we are not
using that because it also does other things and makes the code larger.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
It destroys a few manual alignments, but these seem minor compared to
the benefit of automated code style consistency.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
Trying to use an external board definition according to
https://github.com/micropython/micropython-example-boards on the nrf port
failed with "Invalid BOARD specified". Replacing all ocurrences of
"boards/$(BOARD)" with "$(BOARD_DIR)" following the example of
stm32/Makefile fixes that.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
The documentation for `freeze()` says that:
- If `script` is `None`, all files in `path` will be frozen.
- If `script` is an iterable then `freeze()` is called on all items of the
iterable.
This commit makes sure this behaviour is followed when an empty tuple/list
is passed in for `script` (previously an empty tuple/list froze all files).
Fixes issue #14125.
Signed-off-by: Damien George <damien@micropython.org>
According to the datasheet, the IEN bit to enable the interrupt is in the
MR2 register, not the MR register.
This is just cleanup as the interrupt appears to be enabled by default
after resetting the chip.
Tested on W5100S_EVB_PICO.
During a build the ESP-IDF downloads managed components in the
ports/esp32/managed_components directory, which shouldn't be spellchecked.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
If the heap allocation fails we will crash if we continue, so at least we
can show a clear error message so one can figure out memory allocation was
the problem (instead of just seeing some arbitrary null pointer error
later).
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
Newer versions of gcc (14 and up) have more sophisticated dead-code
detection, and the asm clobbers list needs to contain "memory" to inform
the compiler that the asm code actually does something.
Tested that adding this "memory" line does not change the generated code on
ARM Thumb2, x86-64 and Xtensa targets (using gcc 13.2).
Fixes issue #14115.
Signed-off-by: Damien George <damien@micropython.org>