4 Commits

Author	SHA1	Message	Date
iabdalkader	f187c77da8	shared/runtime/pyexec: Add helper function to execute a vstr. ... Add `pyexec_vstr()` to execute Python code from a vstr source. Signed-off-by: iabdalkader <i.abdalkader@gmail.com>	2025-03-14 17:10:35 +11:00
Damien George	69c25ea865	shared/runtime/pyexec: Make a raised SystemExit always do a forced exit. ... The current situation with SystemExit and soft reset is the following: - `sys.exit()` follows CPython and just raises `SystemExit`. - On the unix port, raising `SystemExit` quits the application/MicroPython, whether at the REPL or in code (this follows CPython behaviour). - On bare-metal ports, raising `SystemExit` at the REPL does nothing, raising it in code will stop the code and drop into the REPL. - `machine.soft_reset()` raises `SystemExit` but with a special flag set, and bare-metal targets check this flag when it propagates to the top-level and do a soft reset when they receive it. The original idea here was that a bare-metal target can't "quit" like the unix port can, and so dropping to the REPL was considered the same as "quit". But this bare-metal behaviour is arguably inconsistent with unix, and "quit" should mean terminate everything, including REPL access. This commit changes the behaviour to the following, which is more consistent: - Raising `SystemExit` on a bare-metal port will do a soft reset (unless the exception is caught by the application). - `machine.soft_reset()` is now equivalent to `sys.exit()`. - unix port behaviour remains unchanged. Tested running the test suite on an stm32 board and everything still passes, in particular tests that skip by raising `SystemExit` still correctly skip. Signed-off-by: Damien George <damien@micropython.org>	2024-07-20 12:13:14 +10:00
David Grayson	c046b23ea2	shared/runtime/pyexec: Don't allow Ctrl+C to interrupt frozen boot code. ... Helps prevent the filesystem from getting formatted by mistake, among other things. For example, on a Pico board, entering Ctrl+D and Ctrl+C fast many times will eventually wipe the filesystem (without warning or notice). Further rationale: Ctrl+C is used a lot by automation scripts (eg mpremote) and UI's (eg Mu, Thonny) to get the board into a known state. If the board is not responding for a short time then it's not possible to know if it's just a slow start up (eg in _boot.py), or an infinite loop in the main application. The former should not be interrupted, but the latter should. The only way to distinguish these two cases would be to wait "long enough", and if there's nothing on the serial after "long enough" then assume it's running the application and Ctrl+C should break out of it. But defining "long enough" is impossible for all the different boards and their possible behaviour. The solution in this commit is to make it so that frozen start-up code cannot be interrupted by Ctrl+C. That code then effectively acts like normal C start-up code, which also cannot be interrupted. Note: on the stm32 port this was never seen as an issue because all start-up code is in C. But now other ports start to put more things in _boot.py and so this problem crops up. Signed-off-by: David Grayson <davidegrayson@gmail.com>	2023-04-05 10:38:50 +10:00
Damien George	4d546713ec	shared: Introduce new top-level dir and move 1st party lib code there. ... This commit moves all first-party code developed for this project from lib/ to shared/, so that lib/ now only contains third-party code. The following directories are moved as-is from lib to shared: lib/libc -> shared/libc lib/memzip -> shared/memzip lib/netutils -> shared/netutils lib/timeutils -> shared/timeutils lib/upytesthelper -> shared/upytesthelper All files in lib/embed/ have been moved to shared/libc/. lib/mp-readline has been moved to shared/readline. lib/utils has been moved to shared/runtime, with the exception of lib/utils/printf.c which has been moved to shared/libc/printf.c. Signed-off-by: Damien George <damien@micropython.org>	2021-07-12 17:07:36 +10:00