The STATIC macro was introduced a very long time ago in commit
d5df6cd44a. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
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>
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>
Also move MICROPY_PY_PENDSV_ENTER/REENTER/EXIT to mphalport.h, for ports
where these are not already there.
This helps separate the hardware implementation of these macros from the
MicroPython configuration (eg for renesas-ra and stm32, the IRQ static
inline helper functions can now be moved to irq.h).
Signed-off-by: Damien George <damien@micropython.org>
In CPython, `_thread.start_new_thread()` returns an ID that is the same ID
that is returned by `_thread.get_ident()`. The current MicroPython
implementation of `_thread.start_new_thread()` always returns `None`.
This modifies the required functions to return a value. The native thread
id is returned since this can be used for interop with other functions, for
example, `pthread_kill()` on *nix. `_thread.get_ident()` is also modified
to return the native thread id so that the values match and avoids the need
for a separate `native_id` attribute.
Fixes issue #12153.
Signed-off-by: David Lechner <david@pybricks.com>
When a flash write/erase is in progress, we need to ensure that the
other core cannot be using XIP.
This also implements MICROPY_BEGIN_ATOMIC_SECTION as a full mutex, which
is necessary as it's used to syncronise access to things like the scheduler
queue.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Prior to this commit the following code would lock up the device when
Ctrl-D is entered at the REPL:
import gc, _thread
def collect_thread():
while True:
gc.collect()
_thread.start_new_thread(collect_thread, [])
Fixes part of #8494.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The stack (and arg) of core1 is itself a root pointer, not just the entries
in it. Without this fix the GC could reclaim the entire stack (and
argument object).
Fixes issues #7124 and #7981.
Any code running on core1 should be stopped on soft-reset (the GC heap is
reset so if code continues to run on core1 it will see corrupt memory).
Signed-off-by: Damien George <damien@micropython.org>
This commit adds a new port "rp2" which targets the new Raspberry Pi RP2040
microcontroller.
The build system uses pure cmake (with a small Makefile wrapper for
convenience). The USB driver is TinyUSB, and there is a machine module
with most of the standard classes implemented. Some examples are provided
in the examples/rp2/ directory.
Work done in collaboration with Graham Sanderson.
Signed-off-by: Damien George <damien@micropython.org>
Angus Gratton