CPython says thread identifier is a "nonzero integer", so rp2 should use a
1-indexed core number rather than 0-indexed. This fixes the
thread/thread_ident1 test failure on rp2 port.
Unfortunately this may be a breaking change for rp2 code which makes a
hard-coded comparison of thread identifier to 0 or 1.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
If there are any free chunks found then it's better to sweep the filesystem
and use the available chunks, rather than error out with ENOSPC when there
is in fact a bit of space remaining.
Signed-off-by: Damien George <damien@micropython.org>
Increases firmware size by +140 bytes and uses +4 extra bytes of RAM, but
allows the test suite to run without crashing.
Signed-off-by: Damien George <damien@micropython.org>
Flash sectors should start counting at 0 for each bank. This commit makes
sure that is the case on all H5 and H7 MCUs, by using `get_page()` instead
of `flash_get_sector_info()`.
Signed-off-by: Damien George <damien@micropython.org>
This commit removes the need for a separate `flash_cache_sector_id`
variable, instead using `flash_cache_sector_start` to indicate which sector
is curretly cached (and -1 indicates no sector).
Signed-off-by: Damien George <damien@micropython.org>
An erase sector sits in a given flash bank and some MCUs have two flash
banks. If trying to erase a range of sectors and that range crosses from
one flash bank into the next, the original implementation of
`flash_erase()` would not handle this case and would do the wrong thing.
This commit changes `flash_erase()` to only erase a single sector, which
sidesteps the need to handle flash-bank-crossing. Most callers of this
function only need to erase a single sector anyway.
Signed-off-by: Damien George <damien@micropython.org>
Newer STM32 parts have homogeneous flash layout, and in this case the MCU
configuration and page/sector calculation can be simplified. The affected
functions are `flash_is_valid_addr()` and `flash_get_sector_info()`, which
are now simpler for homogeneous flash.
Signed-off-by: Damien George <damien@micropython.org>
This commit replaces the linker symbol `_mboot_writable_flash_start` with
`_mboot_protected_flash_start` and `_mboot_protected_flash_end_exclusive`,
to provide better configuration of the protected flash area.
Signed-off-by: Damien George <damien@micropython.org>
Following ad806df857 where the
MICROPY_PY_PENDSV_ENTER/REENTER/EXIT macro definitions were moved to
mphalport.h.
Signed-off-by: Damien George <damien@micropython.org>
Prior to this commit there is a potential deadlock in
mp_thread_begin_atomic_section(), when obtaining the atomic_mutex, in the
following situation:
- main thread calls mp_thread_begin_atomic_section() (for whatever reason,
doesn't matter)
- the second core is running so the main thread grabs the mutex via the
call mp_thread_mutex_lock(&atomic_mutex, 1), and this succeeds
- before the main thread has a chance to run save_and_disable_interrupts()
a USB IRQ comes in and the main thread jumps off to process this IRQ
- that USB processing triggers a call to the dcd_event_handler() wrapper
from commit bcbdee2357
- that then calls mp_sched_schedule_node()
- that then attempts to obtain the atomic section, calling
mp_thread_begin_atomic_section()
- that call then blocks trying to obtain atomic_mutex
- core0 is now deadlocked on itself, because the main thread has the mutex
but the IRQ handler (which preempted the main thread) is blocked waiting
for the mutex, which will never be free
The solution in this commit is to use mutex enter/exit functions that also
atomically disable/restore interrupts.
Fixes issues #12980 and #13288.
Signed-off-by: Damien George <damien@micropython.org>
Using the multicore lockout feature in the general atomic section makes it
much more difficult to get correct.
Signed-off-by: Damien George <damien@micropython.org>
This commit enables additional features for SAMD21 with external flash:
- Viper and native code support. On a relatively slow devices, viper and
native code can be helpful.
- Freeze the asyncio scripts and add the select module.
- Enable Framebuffer support.
- Enable UART flow control.
- Enable a few more features from the extra features set.
Drop onewire and asyncio support from SAMD21 firmware without external
flash, leaving a little bit more room for future extensions. Asyncio was
anyhow incomplete.
Signed-off-by: robert-hh <robert@hammelrath.com>
RTC is enabled on all boards. Therefore the conditional compile is not
needed. Removing it simplifies the source code a little bit.
Signed-off-by: robert-hh <robert@hammelrath.com>
Instead, configure the default once at compile-time. This means the GAP
name will no longer be set to default after re-initializing Bluetooth.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
This commit implements fairly complete support for the DMA controller in
the rp2 series of microcontrollers. It provides a class for accessing the
DMA channels through a high-level, Pythonic interface, and functions for
setting and manipulating the DMA channel configurations.
Creating an instance of the rp2.DMA class claims one of the processor's DMA
channels. A sensible, per-channel default value for the ctrl register can
be fetched from the DMA.pack_ctrl() function, and the components of this
register can be set via keyword arguments to pack_ctrl().
The read, write, count and ctrl attributes of the DMA class provide
read/write access to the respective registers of the DMA controller. The
config() method allows any or all of these values to be set simultaneously
and adds a trigger keyword argument to allow the setup to immediately be
triggered. The read and write attributes (or keywords in config()) accept
either actual addresses or any object that supports the buffer interface.
The active() method provides read/write control of the channel's activity,
allowing the user to start and stop the channel and test if it is running.
Standard MicroPython interrupt handlers are supported through the irq()
method and the channel can be released either by deleting it and allowing
it to be garbage-collected or with the explicit close() method.
Direct, unfettered access to the DMA controllers registers is provided
through a proxy memoryview() object returned by the DMA.registers attribute
that maps directly onto the memory-mapped registers. This is necessary for
more fine-grained control and is helpful for allowing chaining of DMA
channels.
As a simple example, using DMA to do a fast memory copy just needs:
src = bytearray(32*1024)
dest = bytearray(32*1024)
dma = rp2.DMA()
dma.config(read=src, write=dest, count=len(src) // 4,
ctrl=dma.pack_ctrl(), trigger=True)
# Wait for completion
while dma.active():
pass
This API aims to strike a balance between simplicity and comprehensiveness.
Signed-off-by: Nicko van Someren <nicko@nicko.org>
Signed-off-by: Damien George <damien@micropython.org>
This allows to follow good practice and have libraries live in the lib
folder which means they will be found by the runtime without adding this
path manually at runtime.
Signed-off-by: Sebastian Romero <s.romero@arduino.cc>
MicroPython code may rely on the return value of sys.stdout.buffer.write()
to reflect the number of bytes actually written. While in most scenarios a
write() operation is successful, there are cases where it fails, leading to
data loss. This problem arises because, currently, write() merely returns
the number of bytes it was supposed to write, without indication of
failure.
One scenario where write() might fail, is where USB is used and the
receiving end doesn't read quickly enough to empty the receive buffer. In
that case, write() on the MicroPython side can timeout, resulting in the
loss of data without any indication, a behavior observed notably in
communication between a Pi Pico as a client and a Linux host using the ACM
driver.
A complex issue arises with mp_hal_stdout_tx_strn() when it involves
multiple outputs, such as USB, dupterm and hardware UART. The challenge is
in handling cases where writing to one output is successful, but another
fails, either fully or partially. This patch implements the following
solution:
mp_hal_stdout_tx_strn() attempts to write len bytes to all of the possible
destinations for that data, and returns the minimum successful write
length.
The implementation of this is complicated by several factors:
- multiple outputs may be enabled or disabled at compiled time
- multiple outputs may be enabled or disabled at runtime
- mp_os_dupterm_tx_strn() is one such output, optionally containing
multiple additional outputs
- each of these outputs may or may not be able to report success
- each of these outputs may or may not be able to report partial writes
As a result, there's no single strategy that fits all ports, necessitating
unique logic for each instance of mp_hal_stdout_tx_strn().
Note that addressing sys.stdout.write() is more complex due to its data
modification process ("cooked" output), and it remains unchanged in this
patch. Developers who are concerned about accurate return values from
write operations should use sys.stdout.buffer.write().
This patch might disrupt some existing code, but it's also expected to
resolve issues, considering that the peculiar return value behavior of
sys.stdout.buffer.write() is not well-documented and likely not widely
known. Therefore, it's improbable that much existing code relies on the
previous behavior.
Signed-off-by: Maarten van der Schrieck <maarten@thingsconnected.nl>
This adds support to stm32's mboot for the Microsoft WCID USB 0xee string
and Compatible ID Feature Descriptor. This allows the USB device to
automatically set the default USB driver, so that when the device is
plugged in Windows will assign the winusb driver to it. This means that
USB DFU mode can be used without installing any drivers.
For example this page will work (allow the board to be updated over DFU)
with zero install: https://devanlai.github.io/webdfu/dfu-util/
Tested on Windows 10, Windows can read the 0xee string correctly, and
requests the second special descriptor, which then configures the USB
device to use the winusb driver.
Signed-off-by: Damien George <damien@micropython.org>
This gets back the old heap-size behaviour on ESP32, before auto-split-heap
was introduced: after the heap is grown one time the size is 111936 bytes,
with about 40k left for the IDF. That's enough to start WiFi and do a
HTTPS request.
Signed-off-by: Damien George <damien@micropython.org>
Add new board Silicognition RP2040-Shim, RP2040 with 4 MB of flash
and W5500 drivers included and configured by default for use with
the Silicognition PoE-FeatherWing.
Co-authored-by: Matt Trentini <matt.trentini@gmail.com>
Signed-off-by: Patrick Van Oosterwijck <patrick@silicognition.com>
Some boards have multiple options for these pins, and they don't want to
allow users to initialize a port without explicitly specifying pin numbers.
Signed-off-by: Paul Grayson <paul@pololu.com>
esp8266 doesn't need ets task because the notify is now scheduled (see
commits 7d57037906 and
c60caf1995 for relevant history).
Signed-off-by: Damien George <damien@micropython.org>
Also, IDF v5.1.2 is now supported, just not used by default.
IDF v5.0.2 still builds but we cannot guarantee continued support for this
version moving forward.
Signed-off-by: IhorNehrutsa <IhorNehrutsa@gmail.com>
