Before, both uwTick and mp_hal_ticks_ms() were used as clock source. That
assumes, that these two are synchronous and start with the same value,
which may be not the case for all ports. If the lag between uwTick and
mp_hal_ticks_ms() is larger than the timer interval, the timer would either
rush up until the times are synchronous, or not start until uwTick wraps
over.
As suggested by @dpgeorge, MICROPY_SOFT_TIMER_TICKS_MS is now used in
softtimer.c, which has to be defined in a port's mpconfigport.h with
the variable that holds the SysTick counter.
Note that it's not possible to switch everything in softtimer.c to use
mp_hal_ticks_ms() because the logic in SysTick_Handler that schedules
soft_timer_handler() uses (eg on mimxrt) the uwTick variable directly
(named systick_ms there), and mp_hal_ticks_ms() uses a different source
timer. Thus it is made fully configurable.
The default now includes all sub-components (security, l2cap, etc)
and using the kwarg options is no longer supported.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The default now includes all sub-components (security, l2cap, etc)
and using the kwarg options is no longer supported.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Prior to this commit, on Pico W (where the CYW43 driver is enabled) the PIO
instruction memory was not released on soft reset, so using PIO after a
soft reset would eventually (after a few soft resets) lead to ENOMEM when
allocating a PIO program.
This commit fixes that by tracking the use of PIO memory by this module and
freeing it on soft reset.
Similarly, use of the state machines themselves are tracked and released on
soft reset.
Fixes issue #9003.
Signed-off-by: Damien George <damien@micropython.org>
Make this more generally useful and in line with what the mingw
and unix ports do: 16bit dig size to work on 32bit ports, a
self-contained qstrdefs.preprocessed.h because makemanifest.py
uses that, and a dev variant which effectively puts this to use:
previously the uasyncio module wasn't frozen but instead tests
ran by importing it from the extmod/ directory.
The mpversion.h file must exist before py/ source can be preprocessed,
but this went unnoticed because micropython.vcxproj always calls
MakeVersionHdr before MakeQstrDefs.
The variant.props may have incompatible build options which break
the mpy-cross build and in any case mpy-cross has nothing to do
with variant support.
This is in line with the change made for other ports in d53c3b6a: since
the default output directory already includes the variant name in it
there's no need to add it to the executable as well.
This will ensure that any board with networking support gets:
- webrepl
- mip
- urequests
- ntptime
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This drops the `.cpu` directive from the ARM gchelper_*.s files. Having
this directive breaks the linker when targeting older CPUs (e.g. `-mthumb
-mthumb-interwork` for `-mcpu=arm7tdmi`). The actual target CPU should be
determined by the compiler options.
The exact CPU doesn't actually matter, but rather the supported assembly
instruction set. So the files are renamed to *_thumb1.s and *thumb2.s to
indicate the instruction set support instead of the CPU support.
Signed-off-by: David Lechner <david@pybricks.com>
Prior to this commit, Pin(Pin.OPEN_DRAIN, value=0) would not set the
initial value of the open-drain pin to low, instead it would be high.
Signed-off-by: Damien George <damien@micropython.org>
The mp_plat_print output is already being used by the subsequent call to
mp_obj_print_exception(). And this eliminates all references to printf for
this port (at least in non-debug builds).
Signed-off-by: Damien George <damien@micropython.org>
The delay is 1 ms. It avoids the crashes reported by the
issues #8289, #8792 and #9236 with esp-idf versions >= 4.2, but does
not solve an underlying problem in the esp-idf.
The major setting is about the PHY interface configuration. The
configuration matches the Olimex ESP32 Gateway as well.
Tested with esp-idf v4.2.4 and Olimex ESP32 POE boards.
`esp_eth_ioctl(ETH_CMD_S_MAC_ADDR)` sets the MAC address of the hardware
device, but we also need to notify the upper layers of the change so that
e.g. DHCP work properly.
Add support for various SPI-based ethernet chips (W5500, KSZ8851SNL,
DM9051) to the ESP32 port. This leverages the existing support in ESP-IDF
for these chips -- which configures these chips in "MAC raw" mode -- and
the existing support for network.LAN in the ESP32 port. In particular,
this doesn't leverage the wiznet5k support that is used on the rp2 and
stm32 ports (because that's for native use of lwIP).
Tested on the POE Featherwing (with the SJIRQ solder jumper bridged) and a
ESP32-S3 feather.
A note about the interrupt pin: The W5500 implementation within ESP-IDF
relies on hardware interrupt, and requires the interrupt pin from the W5500
to be wired to a GPIO. This is not the case by default on the Adafruit
Ethernet FeatherWing, which makes it not directly compatible with this
implementation.
Both the direction and the Pin used for ref_clk can now be configured. It
Requires at least idf v4.4. The new keyword arguments to the constructor
are:
- ref_clk_mode=mode: with mode being Pin.IN or Pin.OUT. If it is not set,
then the default configuration is used, which may be configured by
kconfig settings.
- ref_clk=pin_obj: which defines the Pin used for ref_clk. This is either
Pin(0), Pin(16) or Pin(17). No check is done for the pin number. If it
is the wrong one, it simply will not work. Besides that, no harm.
LAN8710 uses the same drivers as LAN8720, so this commit just adds the
names. Alternatively, both could be summarised under LAN87xx, like the
esp-idf does.
Pin defines are:
- For Pico define board pins and the default LED pin (WL_GPIO25).
- For Pico-W define board pins, external pins and the default
LED pin (WL_GPIO0).
- For the Nano-RP2040, define board pins, external pins and
the default LED pin (GPIO25)
- For all other boards, the pins.csv defines the LED pin (if any)
for backwards compatibility with code that assumes there's always
an LED pin.
This commit adds support for generating named pin mappings for all pins
including CPU, board-defined, LED and externally controlled pins. CPU pins
are mapped to `pin_GPIO<n>`, externally-controlled pins are mapped to
`pin_EXT_GPIO<n>`, and defined conditionally (up to 10 pins, and can be
expanded in the future), and they are non-const to allow `machine-pin.c` to
write the pin object fields. Both CPU and externally controlled pins are
generated even if there's no board CSV file; if one exists it will just be
added to board pins.
Handle externally controlled GPIO pins more generically, by removing all
CYW43-specific code from `machine_pin.c`, and adding hooks to initialise,
configure, read and write external pins. This allows any driver for an
on-board module which controls GPIO pins (such as CYW43 or NINA), to
provide its own implementation of those hooks and work seamlessly with
`machine_pin.c`.
This commit uses the REGION_ALIAS GNU linker command to simplify the linker
snippets and consolidate the duplication.
Signed-off-by: Damien George <damien@micropython.org>
To allow the USB to work in cases where there is a lot of filesystem
access, in particular on boot.
For example, registering of the USB CDC interface may fail if:
- the board file system is lfs2 (default), and
- sys.path contains entries for the local file system (default), and
- files are imported by boot.py or main.py from frozen bytecode of the file
system (common) and the file system contains many files, like 100.
In that case the board is very busy with scanning LFS, and registering the
USB interface seems to time out. This commit fixes this by allowing the
USB to make progress during filesystem reads.
Also switch existing MICROPY_EVENT_POLL_HOOK uses in this file to
MICROPY_EVENT_POLL_HOOK_FAST now that the latter macro exists.
When switching from a special function like SPI to an input or output,
there was a brief period after the function was disabled but before the
pin's I/O state was configured, in which the state would be poorly defined.
This fixes the problem by switching off the special function after fully
configuring the I/O state.
Fixes#10226.
Signed-off-by: Paul Grayson <pdg@alum.mit.edu>
There were several places where 32-bit integer could overflow with
frequencies of 2^28 Hz or above (~268 MHz). This fixes those overflows and
also introduces rounding for more accurate duty_ns computations.
Signed-off-by: Paul Grayson <pdg@alum.mit.edu>
This changes the freq() and duty_u16() functions to use more simpler, more
accurate formulas, in particular increasing the frequency accuracy from a
few percent to a fraction of a percent in many cases.
Signed-off-by: Paul Grayson <pdg@alum.mit.edu>
This commit prevents the device from "hanging" when using lightsleep while
the WiFi chip is active.
Whenever the WiFi chip wants to interrupt the microcontroller to notify it
for a new package, it sets the CYW43_PIN_WL_HOST_WAKE pin to high,
triggering an IRQ. However, as polling the chip cannot happen in an
interrupt handler, it subsequently notifies the pendsv-service to do a poll
as soon as the interrupt handler ended. In order to prevent a new
interrupt from happening immediately afterwards, even before the poll has
run, the IRQ handler disables interrupts from the pin.
The first problem occurs, when a WiFi package arrives while the main loop
is in cyw43-code. In order to prevent concurrent access of the hardware,
the network code blocks pendsv from running again while entering lwIP code.
The same holds for direct cyw43 code (like changing the cyw43-gpios, i.e.
the LED on the Pico W). While the pendsv is disabled, interrupts can still
occur to schedule a poll (and disable further interrupts), but it will not
run. This can happen while the microcontroller is anywhere in rp2040 code.
In order to preserve power while waiting for cyw43 responses,
cyw43_configport.h defines CYW43_DO_IOCTL_WAIT and
CYW43_SDPCM_SEND_COMMON_WAIT to __WFI(). While this might work in most
cases, there are 2 edge cases where it fails:
- When an interrupt has already been received by the cyw43 stack, for
example due to an incoming ethernet packet.
- When the interrupt from the cyw43 response comes before the
microcontroller entered the __WFI() instruction.
When that happens, wfi will just block forever as no further interrupts are
received. The only way to safely use wfi to wake up from an interrupt is
inside a critical section, as this delays interrupts until the wfi is
entered, possibly resuming immediately until interrupts are reenabled and
the interrupt handler is run. Additionally this critical section needs to
check whether the interrupt has already been disabled and pendsv was
triggered, as in such a case, wfi can never be woken up, and needs to be
skipped, because there is already a package from the network chip waiting.
Note that this turns cyw43_yield into a nop (and thereby the cyw43-loops
into busy waits) from the second time onwards, as after the first call, a
pendsv request will definitely be pending. More logic could be added, to
explicitly enable the interrupt in this case.
Regarding lightsleep, this code has a similar problem. When an interrupt
occurs during lightsleep, the IRQ and pendsv handler and thereby poll are
run immediately, with the clocks still disabled, causing the SPI transfers
to fail. If we don't want to add complex logic inside the IRQ handler we
need to protect the whole lightsleep procedure form interrupts with a
critical section, exiting out early if an interrupt is pending for whatever
reason. Only then we can start to shut down clocks and only enable
interrupts when the system is ready again. Other interrupt handlers might
also be happy, that they are only run when the system is fully operational.
Tested on a Pico W, calling machine.lightsleep() within an endless loop and
pinging from the outside.
robert-hh