The LwIP interface is removed in wiznet5k_deinit() which is called as part
of the init sequence. Therefore, if using mDNS, then the interface will
need to be re-added when bringing the interface up.
Additionally, this allows to set the hostname from MicroPython code prior
to bringing the interface up and mDNS responding to the (new) hostname.
This allows the hostname to be configured and saved on the flash or be
based on dynamic information such as the MAC or unique_id().
Signed-off-by: Jared Hancock <jared.hancock@centeredsolutions.com>
Getting this test running on stm32- and mimxrt-based boards requires adding
a small delay after constructing the UART so that the initial idle frame
has time to be transmitted before the test starts.
Also, the timing margin needs to account for an additional 1-bit worth of
time on some MCUs.
Thanks to @robert-hh for the esp32, mimxrt and samd settings.
Signed-off-by: Damien George <damien@micropython.org>
The port configuration file tagged callable pointers' LSB on both Arm
and RISC-V variants. This is needed on Arm due to Thumb/Thumb2
code addresses having their LSB set, but on RISC-V this is not required.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
Some ports (eg stm32) configure the FAT driver differently (eg with
multi-partition support) and that leads to a slightly different sequence of
block reads, compared to other configurations (eg rp2).
Comment out the printing in `readblocks()` so the tests are deterministic
(the printing is still useful for debugging).
Signed-off-by: Damien George <damien@micropython.org>
This is a fix for issue #15944, and handles corner cases in the FrameBuffer
code when using stride values where the last line's stride may extend past
the end of the underlying buffer. This commit includes extra tests for
these corner cases.
For example a GS8 format FrameBuffer with a width of 8, height of 2 and
stride of 10 should be able to fit into a buffer of size 18 (10 bytes for
the first horizontal line, and 8 bytes for the second -- the full 10 bytes
are not needed).
Similarly a 1 by 9 FrameBuffer in MONO_VLSB format with a stride of 10
should be able to fit into a buffer of length 11 (10 bytes for the first
8 lines, and then one byte for the 9th line.
Being able to do this is particularly important when cropping the corner of
an existing FrameBuffer, either to copy a sprite or to clip drawing.
Signed-off-by: Corran Webster <cwebster@unital.dev>
This reverts commit c94a3205b0.
The idea behind this reverted commit was that it allowed to reconfigure the
UART to change only the baudrate, which is important in the context of a
PPP connection where the baudrate may be changed as part of the protocol.
Also, other ports like the rp2 port have this behaviour, where individual
parameters of the UART can be changed with the `.init()` method.
But this commit was no good for a few reasons:
1. It's a subtle breaking change to the UART API, because existing code
that constructs or initialises a UART with just the baudrate would
expect all other parameters to be reset to their defaults. But with
this commit those parameters would remain unchanged.
2. Constructing a UART like `UART(1, 9600)` also hits this code path of
only changing the baudrate and does not reset other parameters, which is
unexpected.
3. It doesn't support setting the baudrate via keyword, eg
`UART.init(baudrate=9600)`.
4. The `timeout_char` field is not updated when changing only the baudrate,
which can lead to unexpected timeouts when reading/writing.
Due to point (4), this commit broke the `tests/ports/stm32/uart.py` test,
the `uart.writechar(1)` has a timeout because the `uart.init(2400)` does
not set the `timeout_char` for the new baudrate.
Points (2)-(4) could be fixed, but point (1) (being a breaking change)
would remain as an issue. So the commit is reverted.
Signed-off-by: Damien George <damien@micropython.org>
Prior to this commit, when flushing a UART on the rp2 port, it returns just
before the last character is sent out the wire.
Fix this by waiting until the BUSY flag is cleared.
This also fixes the behaviour of `UART.txdone()` to return `True` only when
the last byte has gone out.
Updated docs and tests to match. The test now checks that UART TX time is
very close to the expected time (prior, it was just testing that the TX
time was less than the expected time).
Signed-off-by: Damien George <damien@micropython.org>
When descriptors are enabled, lookup of the `__get__`, `__set__` and
`__delete__` descriptor methods should not be delegated to `__getattr__`.
That follows CPython behaviour.
Signed-off-by: Damien George <damien@micropython.org>
This fixes a regression introduced in commit
4247921c4e, where this ring-buffer polling
was accidentally put inside the `#if MICROPY_HW_ESP_USB_SERIAL_JTAG`.
Signed-off-by: Andrew Leech <andrew@alelec.net>
Provide stub implementations of localtime_r() and mktime() to avoid
code size increase.
Reported upstream at https://github.com/raspberrypi/pico-sdk/issues/1810
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
NUM_GPIOS amd NUM_EXT_GPIOS are currently hardcoded in make-pins.py, which
makes it difficult to support SoCs with different pin count.
This commit generalises make-pins.py by passing in the pin count in via the
new arguments `--num-gpios` and `--num-ext-gpios`. These default to the
current values supported by Pico, namely 30/10. This can be changed with
PICO_NUM_GPIOS and PICO_NUM_EXT_GPIOS in `mpconfigboard.cmake`.
Signed-off-by: Damien George <damien@micropython.org>
Add support for 32 and 48 pin variants of RP2350.
Add new `PIO.gpio_base()` method, mirroring the Pico SDK.
Signed-off-by: Phil Howard <phil@gadgetoid.com>
Signed-off-by: Damien George <damien@micropython.org>
This commit separates various build settings and include files that are
specific to RP2040 and RP2350, and uses the aon_timer interface instead of
rtc, to work across both MCU variants.
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Phil Howard <phil@gadgetoid.com>
Two new bits were added to the ctrl register, and existing bits were
shifted, so use DMA_CH0_CTRL_TRIG_xxx constants to generalise the code.
Signed-off-by: Damien George <damien@micropython.org>
This isn't fully working, the CPU often wakes up early. That will be fixed
when a newer version of pico-sdk is released.
Signed-off-by: Damien George <damien@micropython.org>
Check a target exists before accessing properties. Otherwise
usermod_gather_sources would recurse into garbage property names and break.
Signed-off-by: Phil Howard <phil@gadgetoid.com>
A long time ago when there was only the `stm` port, Ctrl-C would trigger a
preemptive NLR jump to break out of running code. Then in commit
124df6f8d0 a more general approach to
asynchronous `KeyboardInterrupt` exceptions was implemented, and `stmhal`
supported both approaches, with the general (soft) interrupt taking
priority.
Then in commit bc1488a05f `pyboard.py` was
updated with a corresponding change to make it issue a double Ctrl-C to
break out of any existing code when entering the raw REPL (two Ctrl-C
characters were sent in order to more reliably trigger the preemptive NLR
jump).
No other port has preemptive NLR jumps and so a double Ctrl-C doesn't
really behave any differently to a single Ctrl-C: with USB CDC the double
Ctrl-C would most likely be in the same USB packet and so processed in the
same low-level USB callback, so it's just setting the keyboard interrupt
flag twice in a row. The VM/runtime then just sees one keyboard interrupt
and acts as though only one Ctrl-C was sent.
This commit changes the double Ctrl-C to a single Ctrl-C in `pyboard.py`
and `mpremote`. That keeps things as simple as they need to be.
Signed-off-by: Damien George <damien@micropython.org>
Commit 69c25ea865 made raising `SystemExit`
do a soft reset (on bare-metal targets). This means that any test which is
skipped by a target (by raising `SystemExit`) will trigger a soft reset on
that target, and then it must execute its startup code, such as `boot.py`.
If the timing is right, this startup code can be unintentionally
interrupted by the test runner when preparing the next test, because the
test runner enters the raw REPL again via a Ctrl-C Ctrl-A ctrl-D sequence
(in `Pyboard.enter_raw_repl()`).
When this happens (`boot.py` is interrupted) the target may not be set up
correctly, and it may (in the case of stm32 boards) flash LEDs and take
extra time, slowing down the test run.
Fix this by explicitly waiting for the target to finish its soft reset when
it skips a test.
Signed-off-by: Damien George <damien@micropython.org>
