As per PEP 485, this function appeared in for Python 3.5. Configured via
MICROPY_PY_MATH_ISCLOSE which is disabled by default, but enabled for the
ports which already have MICROPY_PY_MATH_SPECIAL_FUNCTIONS enabled.
Before this patch I2C transactions using a hardware I2C peripheral on F0/F7
MCUs would not correctly generate the I2C restart condition, and instead
would generate a stop followed by a start. This is because the CR2 AUTOEND
bit was being set before CR2 START when the peripheral already had the I2C
bus from a previous transaction that did not generate a stop.
As a consequence all combined transactions, eg read-then-write for an I2C
memory transfer, generated a stop condition after the first transaction and
didn't generate a stop at the very end (but still released the bus). Some
I2C devices require a repeated start to function correctly.
This patch fixes this by making sure the CR2 AUTOEND bit is set after the
start condition and slave address have been fully transferred out.
Replaces the `SDKCONFIG` makefile variable with `BOARD`. Defaults to
BOARD=GENERIC. spiram can be enabled with `BOARD=GENERIC_SPIRAM`
Add example definition for TINYPICO, currently identical to GENERIC_SPIRAM
but with custom board/SoC names for the uPy banner.
They are both enabled by default, but can be disabled by defining
MICROPY_HW_ENABLE_MDNS_QUERIES and/or MICROPY_HW_ENABLE_MDNS_RESPONDER to
0. The hostname for the responder is currently taken from
tcpip_adapter_get_hostname() but should eventually be configurable.
This commit adds the connect() method to the PPP interface and requires
that connect() be called after active(1). This is a breaking change for
the PPP API.
With the connect() method it's now possible to pass in authentication
information for PAP/CHAP, eg:
ppp.active(1)
ppp.connect(authmode=ppp.AUTH_PAP, username="user", "password="password")
If no authentication is needed simply call connect() without any
parameters. This will get the original behaviour of calling active(1).
Some SD/MMC breakout boards don't support 4-bit bus mode. This adds a new
macro MICROPY_HW_SDMMC_BUS_WIDTH that allows each board to define the width
of the SD/MMC bus interface used on that board, defaulting to 4 bits.
The previous version did not work on MCUs that only had USB device mode
(compared to OTG) because of the handling of NAK. And this previous
handling of NAK had a race condition where a new packet could come in
before USBD_HID_SetNAK was called (since USBD_HID_ReceivePacket clears NAK
as part of its operation). Furthermore, the double buffering of incoming
reports was not working, only one buffer could be used at a time.
This commit rewrites the HID interface code to have a single incoming
buffer, and only calls USBD_HID_ReceivePacket after the user has read the
incoming report (similar to how the VCP does its flow control). As such,
USBD_HID_SetNAK and USBD_HID_ClearNAK are no longer needed.
API functionality from the user's point of view should be unchanged with
this commit.
On this port the GIL is enabled and everything works under the assumption
of the GIL, ie that a given task has exclusive access to the uPy state, and
any ISRs interrupt the current task and therefore the ISR inherits
exclusive access to the uPy state for the duration of its execution.
If the MicroPython tasks are not pinned to a specific core then an ISR may
be executed on a different core to the task, making it possible for the
main task and an ISR to execute in parallel, breaking the assumption of the
GIL.
The easiest and safest fix for this is to pin all MicroPython related code
to the same CPU core, as done by this patch. Then any ISR that accesses
MicroPython state must be registered from a MicroPython task, to ensure it
is invoked on the same core.
See issue #4895.
The C++ standard forbids redefining keywords, like inline and alignof, so
guard these definitions to avoid that, allowing to include the MicroPython
headers by C++ code.
This new series of MCUs is similar to the L4 series with an additional
Cortex-M0 coprocessor. The firmware for the wireless stack must be managed
separately and MicroPython does not currently interface to it. Supported
features so far include: RTC, UART, USB, internal flash filesystem.
The new configurations MICROPY_HW_USB_MSC and MICROPY_HW_USB_HID can be
used by a board to enabled or disable MSC and/or HID. They are both
enabled by default.
In a non-thread build, using &_ram_end as the top-of-stack is no longer
correct because the stack is not always at the very top end of RAM. See
eg 04c7cdb668 and
3786592097. The correct value to use is
&_estack, which is the value stored in MP_STATE_THREAD(stack_top), and
using the same code for both thread and non-thread builds makes the code
cleaner.
stm32lib now provides system_stm32XXxx.c source files for all MCU variants,
which includes SystemInit and prescaler tables. Since these are quite
standard and don't need to be changed, switch to use them instead of custom
variants, making the start-up code cleaner.
The SystemInit code in stm32lib was checked and is equivalent to what is
removed from the stm32 port in this commit.
Without this you often don't get any DNS server from your network provider.
Additionally, setting your own DNS _does not work_ without this option set
(which could be a bug in the PPP stack).
This is a start to make a more consistent machine.RTC class across ports.
The stm32 pyb.RTC class at least has the datetime() method which behaves
the same as esp8266 and esp32, and with this patch the ntptime.py script
now works with stm32.
If both FS and HS USB peripherals are enabled for a board then the active
one used for the REPL will now be auto-detected, by checking to see if both
the DP and DM lines are actively pulled low. By default the code falls
back to use MICROPY_HW_USB_MAIN_DEV if nothing can be detected.
When going out of memory-mapped mode to do a control transfer to the QSPI
flash, the MPU settings must be changed to forbid access to the memory
mapped region. And any ongoing transfer (eg memory mapped continuous read)
must be aborted.
The Cortex-M7 CPU will do speculative loads from any memory location that
is not explicitly forbidden. This includes the QSPI memory-mapped region
starting at 0x90000000 and with size 256MiB. Speculative loads to this
QSPI region may 1) interfere with the QSPI peripheral registers (eg the
address register) if the QSPI is not in memory-mapped mode; 2) attempt to
access data outside the configured size of the QSPI flash when it is in
memory-mapped mode. Both of these scenarios will lead to issues with the
QSPI peripheral (eg Cortex bus lock up in scenario 2).
To prevent such speculative loads from interfering with the peripheral the
MPU is configured in this commit to restrict access to the QSPI mapped
region: when not memory mapped the entire region is forbidden; when memory
mapped only accesses to the valid flash size are permitted.
When compiled with hard float the system should enable FP access when it
starts or else FP instructions lead to a fault. But this minimal port does
not enable (or use) FP and so, to keep it minimal, switch to use soft
floating point. (This became an issue due to the recent commit
34c04d2319 which saves/restores FP registers
in the NLR state.)
