GitLab

It's better for discoverability to have these examples named `https_xxx.py`
rather than `http_xxx_ssl.py`.
Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>

Also fix a small typo.
Signed-off-by: Angus Gratton <angus@redyak.com.au>

Only when dynamic USB devices are enabled.

The issue here is that when the USB reset triggers, the dynamic USB device
reset callback is called from inside the TinyUSB task.

If that callback tries to print something then it'll call through to
tud_cdc_write_flush(), but TinyUSB hasn't finished updating state yet to
know it's no longer configured. Subsequently it may try to queue a transfer
and then the low-level DCD layer panics.

By explicitly stalling the endpoint first, usbd_edpt_claim() will fail and
tud_cdc_write_flush() returns immediately.

This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>

The W5100 and W5100S only have 4 available sockets and 16kB of socket
buffer.  Allocating 16kB to either the receive or transmit buffer of a
single socket is not allowed, so the current setup does not change the
allocation for socket 0 from the reset default.  ctlwizchip is returning -1
to indicate the error, but the response isn't being inspected and probably
doesn't need to be.
Signed-off-by: Jared Hancock <jared@greezybacon.me>

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>

Signed-off-by: Rick Sorensen <rick.sorensen@gmail.com>

JavaScript semantics are such that the caller of an async function does not
need to await that function for it to run to completion.  This commit makes
that behaviour also apply to top-level async Python code run via
`runPythonAsync()`.
Signed-off-by: Damien George <damien@micropython.org>

This allows using JavaScript for..of on Python iterables.
Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>

To improve efficiency.
Signed-off-by: Damien George <damien@micropython.org>

The `reason` in a rejected promise should be an instance of `Error`.  That
leads to better error messages on the JavaScript side.
Signed-off-by: Damien George <damien@micropython.org>

Fixes issue #14363.
Signed-off-by: Damien George <damien@micropython.org>

This was broken by 5aec051f when adding
support for I2C4 on H7 MCUs.
Signed-off-by: Damien George <damien@micropython.org>

Different MCUs have different requirements for the minimum number of bytes
that can be written to internal flash.
Signed-off-by: Damien George <damien@micropython.org>

The calculations `num_word32 / 4` and `num_word32 / 8` were rounding down
the number of words to program to flash, and therefore possibly truncating
the data (eg mboot could miss writing the final few words of the firmware).

That's fixed in this commit by adding extra logic to program any remaining
words.  And the logic for H5 and H7 is combined.
Signed-off-by: Damien George <damien@micropython.org>

Following change in 899592acSigned-off-by: Damien George <damien@micropython.org>

In case there is a power failure after during this operation, the key must
be the last thing that is written, to indicate valid data.
Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Matt Trentini <matt.trentini@gmail.com>

Signed-off-by: Damien George <damien@micropython.org>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.

[1]: commit dd376a23

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, #20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, #20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, #20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, #20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, #12]
    95e6:       6105            str     r5, [r0, #16]
    95e8:       6146            str     r6, [r0, #20]
    95ea:       6187            str     r7, [r0, #24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, #28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, #32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, #36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, #40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, #44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, #8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

This allows a simple way to run the existing asyncio tests under the
webassembly port, which doesn't support `asyncio.run()`.
Signed-off-by: Damien George <damien@micropython.org>

This commit adds a significant portion of the existing MicroPython asyncio
module to the webassembly port, using parts of the existing asyncio code
and some custom JavaScript parts.

The key difference to the standard asyncio is that this version uses the
JavaScript runtime to do the actual scheduling and waiting on events, eg
Promise fulfillment, timeouts, fetching URLs.

This implementation does not include asyncio.run(). Instead one just uses
asyncio.create_task(..) to start tasks and then returns to the JavaScript.
Then JavaScript will run the tasks.

The implementation here tries to reuse as much existing asyncio code as
possible, and gets all the semantics correct for things like cancellation
and asyncio.wait_for.  An alternative approach would reimplement Task,
Event, etc using JavaScript Promise's.  That approach is very difficult to
get right when trying to implement cancellation (because it's not possible
to cancel a JavaScript Promise).
Signed-off-by: Damien George <damien@micropython.org>

This function exposes `setTimeout()` as an async function.
Signed-off-by: Damien George <damien@micropython.org>

So it can be accessed by a port if needed, for example to see if asyncio
has been imported.
Signed-off-by: Damien George <damien@micropython.org>

When a Promise is rejected on the JavaScript side, the reject reason should
be thrown into the encapsulating generator on the Python side.
Signed-off-by: Damien George <damien@micropython.org>

An exception on the Python side should be passed to the Promise reject
callback on the JavaScript side.
Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>

Otherwise Emscripten allocates it on the Emscripten C stack, which will
overflow for large amounts of code.

Fixes issue #14307.
Signed-off-by: Damien George <damien@micropython.org>

In modularize mode, the `_createMicroPythonModule()` constructor must be
await'ed on, before `Module` is ready to use.
Signed-off-by: Damien George <damien@micropython.org>

To get more insight to firmware size changes when code changes.
Signed-off-by: Damien George <damien@micropython.org>

This a stop-gap until there is a proper fix for this.

This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>

Two cases, one assigning to a slice.
Closes https://github.com/micropython/micropython/issues/13283

Second is extending a slice from itself, similar logic.

In both cases the problem occurs when m_renew causes realloc to move the
buffer, leaving a dangling pointer behind.

There are more complex and hard to fix cases when either argument is a
memoryview into the buffer, currently resizing to a new address breaks
memoryviews into that object.

Reproducing this bug and confirming the fix was done by running the unix
port under valgrind with GC-aware extensions.

Note in default configurations with GIL this bug exists but has no impact
(the free buffer won't be reused while the function is still executing, and
is no longer referenced after it returns).
Signed-off-by: Angus Gratton <angus@redyak.com.au>

This commit swaps the order of the `flags` and `name` struct initialisers
for `mp_obj_type_t`, to fix an incompatibility with C++.  The original
order of the initialiser didn't match the definition of the type, and
although that's still legal C, it's not legal C++.
Signed-off-by: Vonasmic <kasarkal123@gmail.com>

Explicit casts are needed.

Fixes recent changes from 648a7578 and
94002297.
Signed-off-by: stijn <stijn@ignitron.net>

Signed-off-by: Michiel W. Beijen <mb@x14.nl>

When `lightsleep()` is called from within a thread the interrupts may not
be enabled on current core, and thus the call to `lightsleep()` never
completes.

Fixes issue #14092.
Signed-off-by: Simon Wood <simon@mungewell.org>

Fixes: https://github.com/micropython/micropython/issues/14340Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

In the case where an OUT control transfer triggers with wLength==0 (i.e.
all data sent in the SETUP phase, and no additional data phase) the
callbacks were previously implemented to return b"" (i.e. an empty buffer
for the data phase).

However this didn't actually work as intended because b"" can't provide a
RW buffer (needed for OUT transfers with a data phase to write data into),
so actually the endpoint would stall.

The symptom was often that the device process the request (if processing
it in the SETUP phase when all information was already available), but the
host sees the endpoint stall and eventually returns an error.

This commit changes the behaviour so returning True from the SETUP phase of
a control transfer queues a zero length status response.
Signed-off-by: Angus Gratton <angus@redyak.com.au>