|
|
|
/*
|
|
|
|
* This file is part of the MicroPython project, http://micropython.org/
|
|
|
|
*
|
|
|
|
* The MIT License (MIT)
|
|
|
|
*
|
|
|
|
* Copyright (c) 2013, 2014 Damien P. George
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include "py/compile.h"
|
|
|
|
#include "py/runtime.h"
|
|
|
|
#include "py/repl.h"
|
|
|
|
#include "py/gc.h"
|
|
|
|
#include "py/frozenmod.h"
|
|
|
|
#include "py/mphal.h"
|
|
|
|
#if MICROPY_HW_ENABLE_USB
|
|
|
|
#include "irq.h"
|
|
|
|
#include "usb.h"
|
|
|
|
#endif
|
|
|
|
#include "shared/readline/readline.h"
|
|
|
|
#include "shared/runtime/pyexec.h"
|
|
|
|
#include "genhdr/mpversion.h"
|
|
|
|
|
|
|
|
pyexec_mode_kind_t pyexec_mode_kind = PYEXEC_MODE_FRIENDLY_REPL;
|
|
|
|
int pyexec_system_exit = 0;
|
|
|
|
|
|
|
|
#if MICROPY_REPL_INFO
|
|
|
|
STATIC bool repl_display_debugging_info = 0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define EXEC_FLAG_PRINT_EOF (1 << 0)
|
|
|
|
#define EXEC_FLAG_ALLOW_DEBUGGING (1 << 1)
|
|
|
|
#define EXEC_FLAG_IS_REPL (1 << 2)
|
|
|
|
#define EXEC_FLAG_SOURCE_IS_RAW_CODE (1 << 3)
|
|
|
|
#define EXEC_FLAG_SOURCE_IS_VSTR (1 << 4)
|
|
|
|
#define EXEC_FLAG_SOURCE_IS_FILENAME (1 << 5)
|
|
|
|
#define EXEC_FLAG_SOURCE_IS_READER (1 << 6)
|
|
|
|
|
|
|
|
// parses, compiles and executes the code in the lexer
|
|
|
|
// frees the lexer before returning
|
|
|
|
// EXEC_FLAG_PRINT_EOF prints 2 EOF chars: 1 after normal output, 1 after exception output
|
|
|
|
// EXEC_FLAG_ALLOW_DEBUGGING allows debugging info to be printed after executing the code
|
|
|
|
// EXEC_FLAG_IS_REPL is used for REPL inputs (flag passed on to mp_compile)
|
|
|
|
STATIC int parse_compile_execute(const void *source, mp_parse_input_kind_t input_kind, mp_uint_t exec_flags) {
|
|
|
|
int ret = 0;
|
|
|
|
#if MICROPY_REPL_INFO
|
|
|
|
uint32_t start = 0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef MICROPY_BOARD_BEFORE_PYTHON_EXEC
|
|
|
|
MICROPY_BOARD_BEFORE_PYTHON_EXEC(input_kind, exec_flags);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// by default a SystemExit exception returns 0
|
|
|
|
pyexec_system_exit = 0;
|
|
|
|
|
|
|
|
nlr_buf_t nlr;
|
|
|
|
nlr.ret_val = NULL;
|
|
|
|
if (nlr_push(&nlr) == 0) {
|
|
|
|
mp_obj_t module_fun;
|
|
|
|
#if MICROPY_MODULE_FROZEN_MPY
|
|
|
|
if (exec_flags & EXEC_FLAG_SOURCE_IS_RAW_CODE) {
|
|
|
|
// source is a raw_code object, create the function
|
py: Rework bytecode and .mpy file format to be mostly static data.
Background: .mpy files are precompiled .py files, built using mpy-cross,
that contain compiled bytecode functions (and can also contain machine
code). The benefit of using an .mpy file over a .py file is that they are
faster to import and take less memory when importing. They are also
smaller on disk.
But the real benefit of .mpy files comes when they are frozen into the
firmware. This is done by loading the .mpy file during compilation of the
firmware and turning it into a set of big C data structures (the job of
mpy-tool.py), which are then compiled and downloaded into the ROM of a
device. These C data structures can be executed in-place, ie directly from
ROM. This makes importing even faster because there is very little to do,
and also means such frozen modules take up much less RAM (because their
bytecode stays in ROM).
The downside of frozen code is that it requires recompiling and reflashing
the entire firmware. This can be a big barrier to entry, slows down
development time, and makes it harder to do OTA updates of frozen code
(because the whole firmware must be updated).
This commit attempts to solve this problem by providing a solution that
sits between loading .mpy files into RAM and freezing them into the
firmware. The .mpy file format has been reworked so that it consists of
data and bytecode which is mostly static and ready to run in-place. If
these new .mpy files are located in flash/ROM which is memory addressable,
the .mpy file can be executed (mostly) in-place.
With this approach there is still a small amount of unpacking and linking
of the .mpy file that needs to be done when it's imported, but it's still
much better than loading an .mpy from disk into RAM (although not as good
as freezing .mpy files into the firmware).
The main trick to make static .mpy files is to adjust the bytecode so any
qstrs that it references now go through a lookup table to convert from
local qstr number in the module to global qstr number in the firmware.
That means the bytecode does not need linking/rewriting of qstrs when it's
loaded. Instead only a small qstr table needs to be built (and put in RAM)
at import time. This means the bytecode itself is static/constant and can
be used directly if it's in addressable memory. Also the qstr string data
in the .mpy file, and some constant object data, can be used directly.
Note that the qstr table is global to the module (ie not per function).
In more detail, in the VM what used to be (schematically):
qst = DECODE_QSTR_VALUE;
is now (schematically):
idx = DECODE_QSTR_INDEX;
qst = qstr_table[idx];
That allows the bytecode to be fixed at compile time and not need
relinking/rewriting of the qstr values. Only qstr_table needs to be linked
when the .mpy is loaded.
Incidentally, this helps to reduce the size of bytecode because what used
to be 2-byte qstr values in the bytecode are now (mostly) 1-byte indices.
If the module uses the same qstr more than two times then the bytecode is
smaller than before.
The following changes are measured for this commit compared to the
previous (the baseline):
- average 7%-9% reduction in size of .mpy files
- frozen code size is reduced by about 5%-7%
- importing .py files uses about 5% less RAM in total
- importing .mpy files uses about 4% less RAM in total
- importing .py and .mpy files takes about the same time as before
The qstr indirection in the bytecode has only a small impact on VM
performance. For stm32 on PYBv1.0 the performance change of this commit
is:
diff of scores (higher is better)
N=100 M=100 baseline -> this-commit diff diff% (error%)
bm_chaos.py 371.07 -> 357.39 : -13.68 = -3.687% (+/-0.02%)
bm_fannkuch.py 78.72 -> 77.49 : -1.23 = -1.563% (+/-0.01%)
bm_fft.py 2591.73 -> 2539.28 : -52.45 = -2.024% (+/-0.00%)
bm_float.py 6034.93 -> 5908.30 : -126.63 = -2.098% (+/-0.01%)
bm_hexiom.py 48.96 -> 47.93 : -1.03 = -2.104% (+/-0.00%)
bm_nqueens.py 4510.63 -> 4459.94 : -50.69 = -1.124% (+/-0.00%)
bm_pidigits.py 650.28 -> 644.96 : -5.32 = -0.818% (+/-0.23%)
core_import_mpy_multi.py 564.77 -> 581.49 : +16.72 = +2.960% (+/-0.01%)
core_import_mpy_single.py 68.67 -> 67.16 : -1.51 = -2.199% (+/-0.01%)
core_qstr.py 64.16 -> 64.12 : -0.04 = -0.062% (+/-0.00%)
core_yield_from.py 362.58 -> 354.50 : -8.08 = -2.228% (+/-0.00%)
misc_aes.py 429.69 -> 405.59 : -24.10 = -5.609% (+/-0.01%)
misc_mandel.py 3485.13 -> 3416.51 : -68.62 = -1.969% (+/-0.00%)
misc_pystone.py 2496.53 -> 2405.56 : -90.97 = -3.644% (+/-0.01%)
misc_raytrace.py 381.47 -> 374.01 : -7.46 = -1.956% (+/-0.01%)
viper_call0.py 576.73 -> 572.49 : -4.24 = -0.735% (+/-0.04%)
viper_call1a.py 550.37 -> 546.21 : -4.16 = -0.756% (+/-0.09%)
viper_call1b.py 438.23 -> 435.68 : -2.55 = -0.582% (+/-0.06%)
viper_call1c.py 442.84 -> 440.04 : -2.80 = -0.632% (+/-0.08%)
viper_call2a.py 536.31 -> 532.35 : -3.96 = -0.738% (+/-0.06%)
viper_call2b.py 382.34 -> 377.07 : -5.27 = -1.378% (+/-0.03%)
And for unix on x64:
diff of scores (higher is better)
N=2000 M=2000 baseline -> this-commit diff diff% (error%)
bm_chaos.py 13594.20 -> 13073.84 : -520.36 = -3.828% (+/-5.44%)
bm_fannkuch.py 60.63 -> 59.58 : -1.05 = -1.732% (+/-3.01%)
bm_fft.py 112009.15 -> 111603.32 : -405.83 = -0.362% (+/-4.03%)
bm_float.py 246202.55 -> 247923.81 : +1721.26 = +0.699% (+/-2.79%)
bm_hexiom.py 615.65 -> 617.21 : +1.56 = +0.253% (+/-1.64%)
bm_nqueens.py 215807.95 -> 215600.96 : -206.99 = -0.096% (+/-3.52%)
bm_pidigits.py 8246.74 -> 8422.82 : +176.08 = +2.135% (+/-3.64%)
misc_aes.py 16133.00 -> 16452.74 : +319.74 = +1.982% (+/-1.50%)
misc_mandel.py 128146.69 -> 130796.43 : +2649.74 = +2.068% (+/-3.18%)
misc_pystone.py 83811.49 -> 83124.85 : -686.64 = -0.819% (+/-1.03%)
misc_raytrace.py 21688.02 -> 21385.10 : -302.92 = -1.397% (+/-3.20%)
The code size change is (firmware with a lot of frozen code benefits the
most):
bare-arm: +396 +0.697%
minimal x86: +1595 +0.979% [incl +32(data)]
unix x64: +2408 +0.470% [incl +800(data)]
unix nanbox: +1396 +0.309% [incl -96(data)]
stm32: -1256 -0.318% PYBV10
cc3200: +288 +0.157%
esp8266: -260 -0.037% GENERIC
esp32: -216 -0.014% GENERIC[incl -1072(data)]
nrf: +116 +0.067% pca10040
rp2: -664 -0.135% PICO
samd: +844 +0.607% ADAFRUIT_ITSYBITSY_M4_EXPRESS
As part of this change the .mpy file format version is bumped to version 6.
And mpy-tool.py has been improved to provide a good visualisation of the
contents of .mpy files.
In summary: this commit changes the bytecode to use qstr indirection, and
reworks the .mpy file format to be simpler and allow .mpy files to be
executed in-place. Performance is not impacted too much. Eventually it
will be possible to store such .mpy files in a linear, read-only, memory-
mappable filesystem so they can be executed from flash/ROM. This will
essentially be able to replace frozen code for most applications.
Signed-off-by: Damien George <damien@micropython.org>
3 years ago
|
|
|
const mp_frozen_module_t *frozen = source;
|
|
|
|
mp_module_context_t *ctx = m_new_obj(mp_module_context_t);
|
|
|
|
ctx->module.globals = mp_globals_get();
|
|
|
|
ctx->constants = frozen->constants;
|
|
|
|
module_fun = mp_make_function_from_raw_code(frozen->rc, ctx, NULL);
|
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
#if MICROPY_ENABLE_COMPILER
|
|
|
|
mp_lexer_t *lex;
|
|
|
|
if (exec_flags & EXEC_FLAG_SOURCE_IS_VSTR) {
|
|
|
|
const vstr_t *vstr = source;
|
|
|
|
lex = mp_lexer_new_from_str_len(MP_QSTR__lt_stdin_gt_, vstr->buf, vstr->len, 0);
|
lib/utils/pyexec: Add stdin-reader on raw REPL with flow control.
Background: the friendly/normal REPL is intended for human use whereas the
raw REPL is for computer use/automation. Raw REPL is used for things like
pyboard.py script_to_run.py. The normal REPL has built-in flow control
because it echos back the characters. That's not so with raw REPL and flow
control is just implemented by rate limiting the amount of data that goes
in. Currently it's fixed at 256 byte chunks every 10ms. This is sometimes
too fast for slow MCUs or systems with small stdin buffers. It's also too
slow for a lot of higher-end MCUs, ie it could be a lot faster.
This commit adds a new raw REPL mode which includes flow control: the
device will echo back a character after a certain number of bytes are sent
to the host, and the host can use this to regulate the data going out to
the device. The amount of characters is controlled by the device and sent
to the host before communication starts. This flow control allows getting
the maximum speed out of a serial link, regardless of the link or the
device at the other end.
Also, this new raw REPL mode parses and compiles the incoming data as it
comes in. It does this by creating a "stdin reader" object which is then
passed to the lexer. The lexer requests bytes from this "stdin reader"
which retrieves bytes from the host, and does flow control. What this
means is that no memory is used to store the script (in the existing raw
REPL mode the device needs a big buffer to read in the script before it can
pass it on to the lexer/parser/compiler). The only memory needed on the
device is enough to parse and compile.
Finally, it would be possible to extend this new raw REPL to allow bytecode
(.mpy files) to be sent as well as text mode scripts (but that's not done
in this commit).
Some results follow. The test was to send a large 33k script that contains
mostly comments and then prints out the heap, run via pyboard.py large.py.
On PYBD-SF6, prior to this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 34464, free: 357728
No. of 1-blocks: 12, 2-blocks: 2, max blk sz: 2075, max free sz: 22345
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=B........h==h===========================================
00800: ================================================================
00c00: ================================================================
01000: ================================================================
01400: ================================================================
01800: ================================================================
01c00: ================================================================
02000: ================================================================
02400: ================================================================
02800: ================================================================
02c00: ================================================================
03000: ================================================================
03400: ================================================================
03800: ================================================================
03c00: ================================================================
04000: ================================================================
04400: ================================================================
04800: ================================================================
04c00: ================================================================
05000: ================================================================
05400: ================================================================
05800: ================================================================
05c00: ================================================================
06000: ================================================================
06400: ================================================================
06800: ================================================================
06c00: ================================================================
07000: ================================================================
07400: ================================================================
07800: ================================================================
07c00: ================================================================
08000: ================================================================
08400: ===============================================.....h==.........
(349 lines all free)
(the big blob of used memory is the large script).
Same but with this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 1296, free: 390896
No. of 1-blocks: 12, 2-blocks: 3, max blk sz: 40, max free sz: 24420
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=h=B......h==.....h==....................................
(381 lines all free)
The only thing in RAM is the compiled script (and some other unrelated
items).
Time to download before this PR: 1438ms, data rate: 230,799 bits/sec.
Time to download with this PR: 119ms, data rate: 2,788,991 bits/sec.
So it's more than 10 times faster, and uses significantly less RAM.
Results are similar on other boards. On an stm32 board that connects via
UART only at 115200 baud, the data rate goes from 80kbit/sec to
113kbit/sec, so gets close to saturating the UART link without loss of
data.
The new raw REPL mode also supports a single ctrl-C to break out of this
flow-control mode, so that a ctrl-C can always get back to a known state.
It's also backwards compatible with the original raw REPL mode, which is
still supported with the same sequence of commands. The new raw REPL
mode is activated by ctrl-E, which gives an error on devices that do not
support the new mode.
Signed-off-by: Damien George <damien@micropython.org>
4 years ago
|
|
|
} else if (exec_flags & EXEC_FLAG_SOURCE_IS_READER) {
|
|
|
|
lex = mp_lexer_new(MP_QSTR__lt_stdin_gt_, *(mp_reader_t *)source);
|
|
|
|
} else if (exec_flags & EXEC_FLAG_SOURCE_IS_FILENAME) {
|
|
|
|
lex = mp_lexer_new_from_file(source);
|
|
|
|
} else {
|
|
|
|
lex = (mp_lexer_t *)source;
|
|
|
|
}
|
|
|
|
// source is a lexer, parse and compile the script
|
|
|
|
qstr source_name = lex->source_name;
|
|
|
|
mp_parse_tree_t parse_tree = mp_parse(lex, input_kind);
|
|
|
|
module_fun = mp_compile(&parse_tree, source_name, exec_flags & EXEC_FLAG_IS_REPL);
|
|
|
|
#else
|
|
|
|
mp_raise_msg(&mp_type_RuntimeError, MP_ERROR_TEXT("script compilation not supported"));
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
// execute code
|
|
|
|
mp_hal_set_interrupt_char(CHAR_CTRL_C); // allow ctrl-C to interrupt us
|
|
|
|
#if MICROPY_REPL_INFO
|
|
|
|
start = mp_hal_ticks_ms();
|
|
|
|
#endif
|
|
|
|
mp_call_function_0(module_fun);
|
|
|
|
mp_hal_set_interrupt_char(-1); // disable interrupt
|
|
|
|
mp_handle_pending(true); // handle any pending exceptions (and any callbacks)
|
|
|
|
nlr_pop();
|
|
|
|
ret = 1;
|
|
|
|
if (exec_flags & EXEC_FLAG_PRINT_EOF) {
|
|
|
|
mp_hal_stdout_tx_strn("\x04", 1);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// uncaught exception
|
|
|
|
mp_hal_set_interrupt_char(-1); // disable interrupt
|
|
|
|
mp_handle_pending(false); // clear any pending exceptions (and run any callbacks)
|
lib/utils/pyexec: Add stdin-reader on raw REPL with flow control.
Background: the friendly/normal REPL is intended for human use whereas the
raw REPL is for computer use/automation. Raw REPL is used for things like
pyboard.py script_to_run.py. The normal REPL has built-in flow control
because it echos back the characters. That's not so with raw REPL and flow
control is just implemented by rate limiting the amount of data that goes
in. Currently it's fixed at 256 byte chunks every 10ms. This is sometimes
too fast for slow MCUs or systems with small stdin buffers. It's also too
slow for a lot of higher-end MCUs, ie it could be a lot faster.
This commit adds a new raw REPL mode which includes flow control: the
device will echo back a character after a certain number of bytes are sent
to the host, and the host can use this to regulate the data going out to
the device. The amount of characters is controlled by the device and sent
to the host before communication starts. This flow control allows getting
the maximum speed out of a serial link, regardless of the link or the
device at the other end.
Also, this new raw REPL mode parses and compiles the incoming data as it
comes in. It does this by creating a "stdin reader" object which is then
passed to the lexer. The lexer requests bytes from this "stdin reader"
which retrieves bytes from the host, and does flow control. What this
means is that no memory is used to store the script (in the existing raw
REPL mode the device needs a big buffer to read in the script before it can
pass it on to the lexer/parser/compiler). The only memory needed on the
device is enough to parse and compile.
Finally, it would be possible to extend this new raw REPL to allow bytecode
(.mpy files) to be sent as well as text mode scripts (but that's not done
in this commit).
Some results follow. The test was to send a large 33k script that contains
mostly comments and then prints out the heap, run via pyboard.py large.py.
On PYBD-SF6, prior to this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 34464, free: 357728
No. of 1-blocks: 12, 2-blocks: 2, max blk sz: 2075, max free sz: 22345
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=B........h==h===========================================
00800: ================================================================
00c00: ================================================================
01000: ================================================================
01400: ================================================================
01800: ================================================================
01c00: ================================================================
02000: ================================================================
02400: ================================================================
02800: ================================================================
02c00: ================================================================
03000: ================================================================
03400: ================================================================
03800: ================================================================
03c00: ================================================================
04000: ================================================================
04400: ================================================================
04800: ================================================================
04c00: ================================================================
05000: ================================================================
05400: ================================================================
05800: ================================================================
05c00: ================================================================
06000: ================================================================
06400: ================================================================
06800: ================================================================
06c00: ================================================================
07000: ================================================================
07400: ================================================================
07800: ================================================================
07c00: ================================================================
08000: ================================================================
08400: ===============================================.....h==.........
(349 lines all free)
(the big blob of used memory is the large script).
Same but with this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 1296, free: 390896
No. of 1-blocks: 12, 2-blocks: 3, max blk sz: 40, max free sz: 24420
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=h=B......h==.....h==....................................
(381 lines all free)
The only thing in RAM is the compiled script (and some other unrelated
items).
Time to download before this PR: 1438ms, data rate: 230,799 bits/sec.
Time to download with this PR: 119ms, data rate: 2,788,991 bits/sec.
So it's more than 10 times faster, and uses significantly less RAM.
Results are similar on other boards. On an stm32 board that connects via
UART only at 115200 baud, the data rate goes from 80kbit/sec to
113kbit/sec, so gets close to saturating the UART link without loss of
data.
The new raw REPL mode also supports a single ctrl-C to break out of this
flow-control mode, so that a ctrl-C can always get back to a known state.
It's also backwards compatible with the original raw REPL mode, which is
still supported with the same sequence of commands. The new raw REPL
mode is activated by ctrl-E, which gives an error on devices that do not
support the new mode.
Signed-off-by: Damien George <damien@micropython.org>
4 years ago
|
|
|
|
|
|
|
if (exec_flags & EXEC_FLAG_SOURCE_IS_READER) {
|
|
|
|
const mp_reader_t *reader = source;
|
|
|
|
reader->close(reader->data);
|
|
|
|
}
|
|
|
|
|
|
|
|
// print EOF after normal output
|
|
|
|
if (exec_flags & EXEC_FLAG_PRINT_EOF) {
|
|
|
|
mp_hal_stdout_tx_strn("\x04", 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// check for SystemExit
|
|
|
|
if (mp_obj_is_subclass_fast(MP_OBJ_FROM_PTR(((mp_obj_base_t *)nlr.ret_val)->type), MP_OBJ_FROM_PTR(&mp_type_SystemExit))) {
|
|
|
|
// at the moment, the value of SystemExit is unused
|
|
|
|
ret = pyexec_system_exit;
|
|
|
|
} else {
|
|
|
|
mp_obj_print_exception(&mp_plat_print, MP_OBJ_FROM_PTR(nlr.ret_val));
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#if MICROPY_REPL_INFO
|
|
|
|
// display debugging info if wanted
|
|
|
|
if ((exec_flags & EXEC_FLAG_ALLOW_DEBUGGING) && repl_display_debugging_info) {
|
|
|
|
mp_uint_t ticks = mp_hal_ticks_ms() - start; // TODO implement a function that does this properly
|
|
|
|
printf("took " UINT_FMT " ms\n", ticks);
|
|
|
|
// qstr info
|
|
|
|
{
|
|
|
|
size_t n_pool, n_qstr, n_str_data_bytes, n_total_bytes;
|
|
|
|
qstr_pool_info(&n_pool, &n_qstr, &n_str_data_bytes, &n_total_bytes);
|
|
|
|
printf("qstr:\n n_pool=%u\n n_qstr=%u\n "
|
|
|
|
"n_str_data_bytes=%u\n n_total_bytes=%u\n",
|
|
|
|
(unsigned)n_pool, (unsigned)n_qstr, (unsigned)n_str_data_bytes, (unsigned)n_total_bytes);
|
|
|
|
}
|
|
|
|
|
|
|
|
#if MICROPY_ENABLE_GC
|
|
|
|
// run collection and print GC info
|
|
|
|
gc_collect();
|
|
|
|
gc_dump_info();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (exec_flags & EXEC_FLAG_PRINT_EOF) {
|
|
|
|
mp_hal_stdout_tx_strn("\x04", 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef MICROPY_BOARD_AFTER_PYTHON_EXEC
|
|
|
|
MICROPY_BOARD_AFTER_PYTHON_EXEC(input_kind, exec_flags, nlr.ret_val, &ret);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if MICROPY_ENABLE_COMPILER
|
lib/utils/pyexec: Add stdin-reader on raw REPL with flow control.
Background: the friendly/normal REPL is intended for human use whereas the
raw REPL is for computer use/automation. Raw REPL is used for things like
pyboard.py script_to_run.py. The normal REPL has built-in flow control
because it echos back the characters. That's not so with raw REPL and flow
control is just implemented by rate limiting the amount of data that goes
in. Currently it's fixed at 256 byte chunks every 10ms. This is sometimes
too fast for slow MCUs or systems with small stdin buffers. It's also too
slow for a lot of higher-end MCUs, ie it could be a lot faster.
This commit adds a new raw REPL mode which includes flow control: the
device will echo back a character after a certain number of bytes are sent
to the host, and the host can use this to regulate the data going out to
the device. The amount of characters is controlled by the device and sent
to the host before communication starts. This flow control allows getting
the maximum speed out of a serial link, regardless of the link or the
device at the other end.
Also, this new raw REPL mode parses and compiles the incoming data as it
comes in. It does this by creating a "stdin reader" object which is then
passed to the lexer. The lexer requests bytes from this "stdin reader"
which retrieves bytes from the host, and does flow control. What this
means is that no memory is used to store the script (in the existing raw
REPL mode the device needs a big buffer to read in the script before it can
pass it on to the lexer/parser/compiler). The only memory needed on the
device is enough to parse and compile.
Finally, it would be possible to extend this new raw REPL to allow bytecode
(.mpy files) to be sent as well as text mode scripts (but that's not done
in this commit).
Some results follow. The test was to send a large 33k script that contains
mostly comments and then prints out the heap, run via pyboard.py large.py.
On PYBD-SF6, prior to this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 34464, free: 357728
No. of 1-blocks: 12, 2-blocks: 2, max blk sz: 2075, max free sz: 22345
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=B........h==h===========================================
00800: ================================================================
00c00: ================================================================
01000: ================================================================
01400: ================================================================
01800: ================================================================
01c00: ================================================================
02000: ================================================================
02400: ================================================================
02800: ================================================================
02c00: ================================================================
03000: ================================================================
03400: ================================================================
03800: ================================================================
03c00: ================================================================
04000: ================================================================
04400: ================================================================
04800: ================================================================
04c00: ================================================================
05000: ================================================================
05400: ================================================================
05800: ================================================================
05c00: ================================================================
06000: ================================================================
06400: ================================================================
06800: ================================================================
06c00: ================================================================
07000: ================================================================
07400: ================================================================
07800: ================================================================
07c00: ================================================================
08000: ================================================================
08400: ===============================================.....h==.........
(349 lines all free)
(the big blob of used memory is the large script).
Same but with this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 1296, free: 390896
No. of 1-blocks: 12, 2-blocks: 3, max blk sz: 40, max free sz: 24420
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=h=B......h==.....h==....................................
(381 lines all free)
The only thing in RAM is the compiled script (and some other unrelated
items).
Time to download before this PR: 1438ms, data rate: 230,799 bits/sec.
Time to download with this PR: 119ms, data rate: 2,788,991 bits/sec.
So it's more than 10 times faster, and uses significantly less RAM.
Results are similar on other boards. On an stm32 board that connects via
UART only at 115200 baud, the data rate goes from 80kbit/sec to
113kbit/sec, so gets close to saturating the UART link without loss of
data.
The new raw REPL mode also supports a single ctrl-C to break out of this
flow-control mode, so that a ctrl-C can always get back to a known state.
It's also backwards compatible with the original raw REPL mode, which is
still supported with the same sequence of commands. The new raw REPL
mode is activated by ctrl-E, which gives an error on devices that do not
support the new mode.
Signed-off-by: Damien George <damien@micropython.org>
4 years ago
|
|
|
|
|
|
|
// This can be configured by a port (and even configured to a function to be
|
|
|
|
// computed dynamically) to indicate the maximum number of bytes that can be
|
|
|
|
// held in the stdin buffer.
|
|
|
|
#ifndef MICROPY_REPL_STDIN_BUFFER_MAX
|
|
|
|
#define MICROPY_REPL_STDIN_BUFFER_MAX (256)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
typedef struct _mp_reader_stdin_t {
|
|
|
|
bool eof;
|
|
|
|
uint16_t window_max;
|
|
|
|
uint16_t window_remain;
|
|
|
|
} mp_reader_stdin_t;
|
|
|
|
|
|
|
|
STATIC mp_uint_t mp_reader_stdin_readbyte(void *data) {
|
|
|
|
mp_reader_stdin_t *reader = (mp_reader_stdin_t *)data;
|
|
|
|
|
|
|
|
if (reader->eof) {
|
|
|
|
return MP_READER_EOF;
|
|
|
|
}
|
|
|
|
|
|
|
|
int c = mp_hal_stdin_rx_chr();
|
|
|
|
|
|
|
|
if (c == CHAR_CTRL_C || c == CHAR_CTRL_D) {
|
|
|
|
reader->eof = true;
|
|
|
|
mp_hal_stdout_tx_strn("\x04", 1); // indicate end to host
|
|
|
|
if (c == CHAR_CTRL_C) {
|
|
|
|
#if MICROPY_KBD_EXCEPTION
|
|
|
|
MP_STATE_VM(mp_kbd_exception).traceback_data = NULL;
|
|
|
|
nlr_raise(MP_OBJ_FROM_PTR(&MP_STATE_VM(mp_kbd_exception)));
|
|
|
|
#else
|
|
|
|
mp_raise_type(&mp_type_KeyboardInterrupt);
|
|
|
|
#endif
|
|
|
|
} else {
|
|
|
|
return MP_READER_EOF;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (--reader->window_remain == 0) {
|
|
|
|
mp_hal_stdout_tx_strn("\x01", 1); // indicate window available to host
|
|
|
|
reader->window_remain = reader->window_max;
|
|
|
|
}
|
|
|
|
|
|
|
|
return c;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void mp_reader_stdin_close(void *data) {
|
|
|
|
mp_reader_stdin_t *reader = (mp_reader_stdin_t *)data;
|
|
|
|
if (!reader->eof) {
|
|
|
|
reader->eof = true;
|
|
|
|
mp_hal_stdout_tx_strn("\x04", 1); // indicate end to host
|
|
|
|
for (;;) {
|
|
|
|
int c = mp_hal_stdin_rx_chr();
|
|
|
|
if (c == CHAR_CTRL_C || c == CHAR_CTRL_D) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void mp_reader_new_stdin(mp_reader_t *reader, mp_reader_stdin_t *reader_stdin, uint16_t buf_max) {
|
|
|
|
// Make flow-control window half the buffer size, and indicate to the host that 2x windows are
|
|
|
|
// free (sending the window size implicitly indicates that a window is free, and then the 0x01
|
|
|
|
// indicates that another window is free).
|
|
|
|
size_t window = buf_max / 2;
|
|
|
|
char reply[3] = { window & 0xff, window >> 8, 0x01 };
|
|
|
|
mp_hal_stdout_tx_strn(reply, sizeof(reply));
|
|
|
|
|
|
|
|
reader_stdin->eof = false;
|
|
|
|
reader_stdin->window_max = window;
|
|
|
|
reader_stdin->window_remain = window;
|
|
|
|
reader->data = reader_stdin;
|
|
|
|
reader->readbyte = mp_reader_stdin_readbyte;
|
|
|
|
reader->close = mp_reader_stdin_close;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC int do_reader_stdin(int c) {
|
|
|
|
if (c != 'A') {
|
|
|
|
// Unsupported command.
|
|
|
|
mp_hal_stdout_tx_strn("R\x00", 2);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Indicate reception of command.
|
|
|
|
mp_hal_stdout_tx_strn("R\x01", 2);
|
|
|
|
|
|
|
|
mp_reader_t reader;
|
|
|
|
mp_reader_stdin_t reader_stdin;
|
|
|
|
mp_reader_new_stdin(&reader, &reader_stdin, MICROPY_REPL_STDIN_BUFFER_MAX);
|
|
|
|
int exec_flags = EXEC_FLAG_PRINT_EOF | EXEC_FLAG_SOURCE_IS_READER;
|
|
|
|
return parse_compile_execute(&reader, MP_PARSE_FILE_INPUT, exec_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
#if MICROPY_REPL_EVENT_DRIVEN
|
|
|
|
|
|
|
|
typedef struct _repl_t {
|
|
|
|
// This structure originally also held current REPL line,
|
|
|
|
// but it was moved to MP_STATE_VM(repl_line) as containing
|
|
|
|
// root pointer. Still keep structure in case more state
|
|
|
|
// will be added later.
|
|
|
|
// vstr_t line;
|
|
|
|
bool cont_line;
|
|
|
|
bool paste_mode;
|
|
|
|
} repl_t;
|
|
|
|
|
|
|
|
repl_t repl;
|
|
|
|
|
|
|
|
STATIC int pyexec_raw_repl_process_char(int c);
|
|
|
|
STATIC int pyexec_friendly_repl_process_char(int c);
|
|
|
|
|
|
|
|
void pyexec_event_repl_init(void) {
|
|
|
|
MP_STATE_VM(repl_line) = vstr_new(32);
|
|
|
|
repl.cont_line = false;
|
|
|
|
repl.paste_mode = false;
|
|
|
|
// no prompt before printing friendly REPL banner or entering raw REPL
|
|
|
|
readline_init(MP_STATE_VM(repl_line), "");
|
|
|
|
if (pyexec_mode_kind == PYEXEC_MODE_RAW_REPL) {
|
|
|
|
pyexec_raw_repl_process_char(CHAR_CTRL_A);
|
|
|
|
} else {
|
|
|
|
pyexec_friendly_repl_process_char(CHAR_CTRL_B);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC int pyexec_raw_repl_process_char(int c) {
|
|
|
|
if (c == CHAR_CTRL_A) {
|
|
|
|
// reset raw REPL
|
lib/utils/pyexec: Add stdin-reader on raw REPL with flow control.
Background: the friendly/normal REPL is intended for human use whereas the
raw REPL is for computer use/automation. Raw REPL is used for things like
pyboard.py script_to_run.py. The normal REPL has built-in flow control
because it echos back the characters. That's not so with raw REPL and flow
control is just implemented by rate limiting the amount of data that goes
in. Currently it's fixed at 256 byte chunks every 10ms. This is sometimes
too fast for slow MCUs or systems with small stdin buffers. It's also too
slow for a lot of higher-end MCUs, ie it could be a lot faster.
This commit adds a new raw REPL mode which includes flow control: the
device will echo back a character after a certain number of bytes are sent
to the host, and the host can use this to regulate the data going out to
the device. The amount of characters is controlled by the device and sent
to the host before communication starts. This flow control allows getting
the maximum speed out of a serial link, regardless of the link or the
device at the other end.
Also, this new raw REPL mode parses and compiles the incoming data as it
comes in. It does this by creating a "stdin reader" object which is then
passed to the lexer. The lexer requests bytes from this "stdin reader"
which retrieves bytes from the host, and does flow control. What this
means is that no memory is used to store the script (in the existing raw
REPL mode the device needs a big buffer to read in the script before it can
pass it on to the lexer/parser/compiler). The only memory needed on the
device is enough to parse and compile.
Finally, it would be possible to extend this new raw REPL to allow bytecode
(.mpy files) to be sent as well as text mode scripts (but that's not done
in this commit).
Some results follow. The test was to send a large 33k script that contains
mostly comments and then prints out the heap, run via pyboard.py large.py.
On PYBD-SF6, prior to this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 34464, free: 357728
No. of 1-blocks: 12, 2-blocks: 2, max blk sz: 2075, max free sz: 22345
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=B........h==h===========================================
00800: ================================================================
00c00: ================================================================
01000: ================================================================
01400: ================================================================
01800: ================================================================
01c00: ================================================================
02000: ================================================================
02400: ================================================================
02800: ================================================================
02c00: ================================================================
03000: ================================================================
03400: ================================================================
03800: ================================================================
03c00: ================================================================
04000: ================================================================
04400: ================================================================
04800: ================================================================
04c00: ================================================================
05000: ================================================================
05400: ================================================================
05800: ================================================================
05c00: ================================================================
06000: ================================================================
06400: ================================================================
06800: ================================================================
06c00: ================================================================
07000: ================================================================
07400: ================================================================
07800: ================================================================
07c00: ================================================================
08000: ================================================================
08400: ===============================================.....h==.........
(349 lines all free)
(the big blob of used memory is the large script).
Same but with this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 1296, free: 390896
No. of 1-blocks: 12, 2-blocks: 3, max blk sz: 40, max free sz: 24420
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=h=B......h==.....h==....................................
(381 lines all free)
The only thing in RAM is the compiled script (and some other unrelated
items).
Time to download before this PR: 1438ms, data rate: 230,799 bits/sec.
Time to download with this PR: 119ms, data rate: 2,788,991 bits/sec.
So it's more than 10 times faster, and uses significantly less RAM.
Results are similar on other boards. On an stm32 board that connects via
UART only at 115200 baud, the data rate goes from 80kbit/sec to
113kbit/sec, so gets close to saturating the UART link without loss of
data.
The new raw REPL mode also supports a single ctrl-C to break out of this
flow-control mode, so that a ctrl-C can always get back to a known state.
It's also backwards compatible with the original raw REPL mode, which is
still supported with the same sequence of commands. The new raw REPL
mode is activated by ctrl-E, which gives an error on devices that do not
support the new mode.
Signed-off-by: Damien George <damien@micropython.org>
4 years ago
|
|
|
if (vstr_len(MP_STATE_VM(repl_line)) == 2 && vstr_str(MP_STATE_VM(repl_line))[0] == CHAR_CTRL_E) {
|
|
|
|
int ret = do_reader_stdin(vstr_str(MP_STATE_VM(repl_line))[1]);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
goto reset;
|
|
|
|
}
|
|
|
|
mp_hal_stdout_tx_str("raw REPL; CTRL-B to exit\r\n");
|
|
|
|
goto reset;
|
|
|
|
} else if (c == CHAR_CTRL_B) {
|
|
|
|
// change to friendly REPL
|
|
|
|
pyexec_mode_kind = PYEXEC_MODE_FRIENDLY_REPL;
|
|
|
|
vstr_reset(MP_STATE_VM(repl_line));
|
|
|
|
repl.cont_line = false;
|
|
|
|
repl.paste_mode = false;
|
|
|
|
pyexec_friendly_repl_process_char(CHAR_CTRL_B);
|
|
|
|
return 0;
|
|
|
|
} else if (c == CHAR_CTRL_C) {
|
|
|
|
// clear line
|
|
|
|
vstr_reset(MP_STATE_VM(repl_line));
|
|
|
|
return 0;
|
|
|
|
} else if (c == CHAR_CTRL_D) {
|
|
|
|
// input finished
|
|
|
|
} else {
|
|
|
|
// let through any other raw 8-bit value
|
|
|
|
vstr_add_byte(MP_STATE_VM(repl_line), c);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// indicate reception of command
|
|
|
|
mp_hal_stdout_tx_str("OK");
|
|
|
|
|
|
|
|
if (MP_STATE_VM(repl_line)->len == 0) {
|
|
|
|
// exit for a soft reset
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(MP_STATE_VM(repl_line));
|
|
|
|
return PYEXEC_FORCED_EXIT;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ret = parse_compile_execute(MP_STATE_VM(repl_line), MP_PARSE_FILE_INPUT, EXEC_FLAG_PRINT_EOF | EXEC_FLAG_SOURCE_IS_VSTR);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
reset:
|
|
|
|
vstr_reset(MP_STATE_VM(repl_line));
|
|
|
|
mp_hal_stdout_tx_str(">");
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC int pyexec_friendly_repl_process_char(int c) {
|
|
|
|
if (repl.paste_mode) {
|
|
|
|
if (c == CHAR_CTRL_C) {
|
|
|
|
// cancel everything
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
goto input_restart;
|
|
|
|
} else if (c == CHAR_CTRL_D) {
|
|
|
|
// end of input
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
int ret = parse_compile_execute(MP_STATE_VM(repl_line), MP_PARSE_FILE_INPUT, EXEC_FLAG_ALLOW_DEBUGGING | EXEC_FLAG_IS_REPL | EXEC_FLAG_SOURCE_IS_VSTR);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
goto input_restart;
|
|
|
|
} else {
|
|
|
|
// add char to buffer and echo
|
|
|
|
vstr_add_byte(MP_STATE_VM(repl_line), c);
|
|
|
|
if (c == '\r') {
|
|
|
|
mp_hal_stdout_tx_str("\r\n=== ");
|
|
|
|
} else {
|
|
|
|
char buf[1] = {c};
|
|
|
|
mp_hal_stdout_tx_strn(buf, 1);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int ret = readline_process_char(c);
|
|
|
|
|
|
|
|
if (!repl.cont_line) {
|
|
|
|
|
|
|
|
if (ret == CHAR_CTRL_A) {
|
|
|
|
// change to raw REPL
|
|
|
|
pyexec_mode_kind = PYEXEC_MODE_RAW_REPL;
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
pyexec_raw_repl_process_char(CHAR_CTRL_A);
|
|
|
|
return 0;
|
|
|
|
} else if (ret == CHAR_CTRL_B) {
|
|
|
|
// reset friendly REPL
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
py/modsys: Append MicroPython git version and build date to sys.version.
This commit adds the git hash and build date to sys.version. This is
allowed according to CPython docs, and is what PyPy does. The docs state:
A string containing the version number of the Python interpreter plus
additional information on the build number and compiler used.
Eg on CPython:
Python 3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0]'
and PyPy:
Python 2.7.12 (5.6.0+dfsg-4, Nov 20 2016, 10:43:30)
[PyPy 5.6.0 with GCC 6.2.0 20161109] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.version
'2.7.12 (5.6.0+dfsg-4, Nov 20 2016, 10:43:30)\n[PyPy 5.6.0 with GCC ...
With this commit on MicroPython we now have:
MicroPython v1.18-371-g9d08eb024 on 2022-04-28; linux [GCC 11.2.0] v...
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import sys
>>> sys.version
'3.4.0; MicroPython v1.18-371-g9d08eb024 on 2022-04-28'
Note that the start of the banner is the same as the end of sys.version.
This helps to keep code size under control because the string can be reused
by the compiler.
Signed-off-by: Damien George <damien@micropython.org>
3 years ago
|
|
|
mp_hal_stdout_tx_str(MICROPY_BANNER_NAME_AND_VERSION);
|
|
|
|
mp_hal_stdout_tx_str("; " MICROPY_BANNER_MACHINE);
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
#if MICROPY_PY_BUILTINS_HELP
|
|
|
|
mp_hal_stdout_tx_str("Type \"help()\" for more information.\r\n");
|
|
|
|
#endif
|
|
|
|
goto input_restart;
|
|
|
|
} else if (ret == CHAR_CTRL_C) {
|
|
|
|
// break
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
goto input_restart;
|
|
|
|
} else if (ret == CHAR_CTRL_D) {
|
|
|
|
// exit for a soft reset
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(MP_STATE_VM(repl_line));
|
|
|
|
return PYEXEC_FORCED_EXIT;
|
|
|
|
} else if (ret == CHAR_CTRL_E) {
|
|
|
|
// paste mode
|
|
|
|
mp_hal_stdout_tx_str("\r\npaste mode; Ctrl-C to cancel, Ctrl-D to finish\r\n=== ");
|
|
|
|
vstr_reset(MP_STATE_VM(repl_line));
|
|
|
|
repl.paste_mode = true;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!mp_repl_continue_with_input(vstr_null_terminated_str(MP_STATE_VM(repl_line)))) {
|
|
|
|
goto exec;
|
|
|
|
}
|
|
|
|
|
|
|
|
vstr_add_byte(MP_STATE_VM(repl_line), '\n');
|
|
|
|
repl.cont_line = true;
|
|
|
|
readline_note_newline(mp_repl_get_ps2());
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
|
|
|
if (ret == CHAR_CTRL_C) {
|
|
|
|
// cancel everything
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
repl.cont_line = false;
|
|
|
|
goto input_restart;
|
|
|
|
} else if (ret == CHAR_CTRL_D) {
|
|
|
|
// stop entering compound statement
|
|
|
|
goto exec;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mp_repl_continue_with_input(vstr_null_terminated_str(MP_STATE_VM(repl_line)))) {
|
|
|
|
vstr_add_byte(MP_STATE_VM(repl_line), '\n');
|
|
|
|
readline_note_newline(mp_repl_get_ps2());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
exec:;
|
|
|
|
int ret = parse_compile_execute(MP_STATE_VM(repl_line), MP_PARSE_SINGLE_INPUT, EXEC_FLAG_ALLOW_DEBUGGING | EXEC_FLAG_IS_REPL | EXEC_FLAG_SOURCE_IS_VSTR);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
input_restart:
|
|
|
|
vstr_reset(MP_STATE_VM(repl_line));
|
|
|
|
repl.cont_line = false;
|
|
|
|
repl.paste_mode = false;
|
|
|
|
readline_init(MP_STATE_VM(repl_line), mp_repl_get_ps1());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
uint8_t pyexec_repl_active;
|
|
|
|
int pyexec_event_repl_process_char(int c) {
|
|
|
|
pyexec_repl_active = 1;
|
|
|
|
int res;
|
|
|
|
if (pyexec_mode_kind == PYEXEC_MODE_RAW_REPL) {
|
|
|
|
res = pyexec_raw_repl_process_char(c);
|
|
|
|
} else {
|
|
|
|
res = pyexec_friendly_repl_process_char(c);
|
|
|
|
}
|
|
|
|
pyexec_repl_active = 0;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
MP_REGISTER_ROOT_POINTER(vstr_t * repl_line);
|
|
|
|
|
|
|
|
#else // MICROPY_REPL_EVENT_DRIVEN
|
|
|
|
|
|
|
|
int pyexec_raw_repl(void) {
|
|
|
|
vstr_t line;
|
|
|
|
vstr_init(&line, 32);
|
|
|
|
|
|
|
|
raw_repl_reset:
|
|
|
|
mp_hal_stdout_tx_str("raw REPL; CTRL-B to exit\r\n");
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
vstr_reset(&line);
|
|
|
|
mp_hal_stdout_tx_str(">");
|
|
|
|
for (;;) {
|
|
|
|
int c = mp_hal_stdin_rx_chr();
|
|
|
|
if (c == CHAR_CTRL_A) {
|
|
|
|
// reset raw REPL
|
lib/utils/pyexec: Add stdin-reader on raw REPL with flow control.
Background: the friendly/normal REPL is intended for human use whereas the
raw REPL is for computer use/automation. Raw REPL is used for things like
pyboard.py script_to_run.py. The normal REPL has built-in flow control
because it echos back the characters. That's not so with raw REPL and flow
control is just implemented by rate limiting the amount of data that goes
in. Currently it's fixed at 256 byte chunks every 10ms. This is sometimes
too fast for slow MCUs or systems with small stdin buffers. It's also too
slow for a lot of higher-end MCUs, ie it could be a lot faster.
This commit adds a new raw REPL mode which includes flow control: the
device will echo back a character after a certain number of bytes are sent
to the host, and the host can use this to regulate the data going out to
the device. The amount of characters is controlled by the device and sent
to the host before communication starts. This flow control allows getting
the maximum speed out of a serial link, regardless of the link or the
device at the other end.
Also, this new raw REPL mode parses and compiles the incoming data as it
comes in. It does this by creating a "stdin reader" object which is then
passed to the lexer. The lexer requests bytes from this "stdin reader"
which retrieves bytes from the host, and does flow control. What this
means is that no memory is used to store the script (in the existing raw
REPL mode the device needs a big buffer to read in the script before it can
pass it on to the lexer/parser/compiler). The only memory needed on the
device is enough to parse and compile.
Finally, it would be possible to extend this new raw REPL to allow bytecode
(.mpy files) to be sent as well as text mode scripts (but that's not done
in this commit).
Some results follow. The test was to send a large 33k script that contains
mostly comments and then prints out the heap, run via pyboard.py large.py.
On PYBD-SF6, prior to this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 34464, free: 357728
No. of 1-blocks: 12, 2-blocks: 2, max blk sz: 2075, max free sz: 22345
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=B........h==h===========================================
00800: ================================================================
00c00: ================================================================
01000: ================================================================
01400: ================================================================
01800: ================================================================
01c00: ================================================================
02000: ================================================================
02400: ================================================================
02800: ================================================================
02c00: ================================================================
03000: ================================================================
03400: ================================================================
03800: ================================================================
03c00: ================================================================
04000: ================================================================
04400: ================================================================
04800: ================================================================
04c00: ================================================================
05000: ================================================================
05400: ================================================================
05800: ================================================================
05c00: ================================================================
06000: ================================================================
06400: ================================================================
06800: ================================================================
06c00: ================================================================
07000: ================================================================
07400: ================================================================
07800: ================================================================
07c00: ================================================================
08000: ================================================================
08400: ===============================================.....h==.........
(349 lines all free)
(the big blob of used memory is the large script).
Same but with this PR:
$ ./pyboard.py large.py
stack: 524 out of 23552
GC: total: 392192, used: 1296, free: 390896
No. of 1-blocks: 12, 2-blocks: 3, max blk sz: 40, max free sz: 24420
GC memory layout; from 2001a3f0:
00000: h=hhhh=======================================hhBShShh==h=======h
00400: =====hh=h=B......h==.....h==....................................
(381 lines all free)
The only thing in RAM is the compiled script (and some other unrelated
items).
Time to download before this PR: 1438ms, data rate: 230,799 bits/sec.
Time to download with this PR: 119ms, data rate: 2,788,991 bits/sec.
So it's more than 10 times faster, and uses significantly less RAM.
Results are similar on other boards. On an stm32 board that connects via
UART only at 115200 baud, the data rate goes from 80kbit/sec to
113kbit/sec, so gets close to saturating the UART link without loss of
data.
The new raw REPL mode also supports a single ctrl-C to break out of this
flow-control mode, so that a ctrl-C can always get back to a known state.
It's also backwards compatible with the original raw REPL mode, which is
still supported with the same sequence of commands. The new raw REPL
mode is activated by ctrl-E, which gives an error on devices that do not
support the new mode.
Signed-off-by: Damien George <damien@micropython.org>
4 years ago
|
|
|
if (vstr_len(&line) == 2 && vstr_str(&line)[0] == CHAR_CTRL_E) {
|
|
|
|
int ret = do_reader_stdin(vstr_str(&line)[1]);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
vstr_reset(&line);
|
|
|
|
mp_hal_stdout_tx_str(">");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
goto raw_repl_reset;
|
|
|
|
} else if (c == CHAR_CTRL_B) {
|
|
|
|
// change to friendly REPL
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(&line);
|
|
|
|
pyexec_mode_kind = PYEXEC_MODE_FRIENDLY_REPL;
|
|
|
|
return 0;
|
|
|
|
} else if (c == CHAR_CTRL_C) {
|
|
|
|
// clear line
|
|
|
|
vstr_reset(&line);
|
|
|
|
} else if (c == CHAR_CTRL_D) {
|
|
|
|
// input finished
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
// let through any other raw 8-bit value
|
|
|
|
vstr_add_byte(&line, c);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// indicate reception of command
|
|
|
|
mp_hal_stdout_tx_str("OK");
|
|
|
|
|
|
|
|
if (line.len == 0) {
|
|
|
|
// exit for a soft reset
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(&line);
|
|
|
|
return PYEXEC_FORCED_EXIT;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ret = parse_compile_execute(&line, MP_PARSE_FILE_INPUT, EXEC_FLAG_PRINT_EOF | EXEC_FLAG_SOURCE_IS_VSTR);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int pyexec_friendly_repl(void) {
|
|
|
|
vstr_t line;
|
|
|
|
vstr_init(&line, 32);
|
|
|
|
|
|
|
|
friendly_repl_reset:
|
py/modsys: Append MicroPython git version and build date to sys.version.
This commit adds the git hash and build date to sys.version. This is
allowed according to CPython docs, and is what PyPy does. The docs state:
A string containing the version number of the Python interpreter plus
additional information on the build number and compiler used.
Eg on CPython:
Python 3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0]'
and PyPy:
Python 2.7.12 (5.6.0+dfsg-4, Nov 20 2016, 10:43:30)
[PyPy 5.6.0 with GCC 6.2.0 20161109] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.version
'2.7.12 (5.6.0+dfsg-4, Nov 20 2016, 10:43:30)\n[PyPy 5.6.0 with GCC ...
With this commit on MicroPython we now have:
MicroPython v1.18-371-g9d08eb024 on 2022-04-28; linux [GCC 11.2.0] v...
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import sys
>>> sys.version
'3.4.0; MicroPython v1.18-371-g9d08eb024 on 2022-04-28'
Note that the start of the banner is the same as the end of sys.version.
This helps to keep code size under control because the string can be reused
by the compiler.
Signed-off-by: Damien George <damien@micropython.org>
3 years ago
|
|
|
mp_hal_stdout_tx_str(MICROPY_BANNER_NAME_AND_VERSION);
|
|
|
|
mp_hal_stdout_tx_str("; " MICROPY_BANNER_MACHINE);
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
#if MICROPY_PY_BUILTINS_HELP
|
|
|
|
mp_hal_stdout_tx_str("Type \"help()\" for more information.\r\n");
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// to test ctrl-C
|
|
|
|
/*
|
|
|
|
{
|
|
|
|
uint32_t x[4] = {0x424242, 0xdeaddead, 0x242424, 0xdeadbeef};
|
|
|
|
for (;;) {
|
|
|
|
nlr_buf_t nlr;
|
|
|
|
printf("pyexec_repl: %p\n", x);
|
|
|
|
mp_hal_set_interrupt_char(CHAR_CTRL_C);
|
|
|
|
if (nlr_push(&nlr) == 0) {
|
|
|
|
for (;;) {
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
printf("break\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*/
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
input_restart:
|
|
|
|
|
|
|
|
#if MICROPY_HW_ENABLE_USB
|
|
|
|
if (usb_vcp_is_enabled()) {
|
|
|
|
// If the user gets to here and interrupts are disabled then
|
|
|
|
// they'll never see the prompt, traceback etc. The USB REPL needs
|
|
|
|
// interrupts to be enabled or no transfers occur. So we try to
|
|
|
|
// do the user a favor and reenable interrupts.
|
|
|
|
if (query_irq() == IRQ_STATE_DISABLED) {
|
|
|
|
enable_irq(IRQ_STATE_ENABLED);
|
|
|
|
mp_hal_stdout_tx_str("MPY: enabling IRQs\r\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// If the GC is locked at this point there is no way out except a reset,
|
|
|
|
// so force the GC to be unlocked to help the user debug what went wrong.
|
|
|
|
if (MP_STATE_THREAD(gc_lock_depth) != 0) {
|
|
|
|
MP_STATE_THREAD(gc_lock_depth) = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
vstr_reset(&line);
|
|
|
|
int ret = readline(&line, mp_repl_get_ps1());
|
|
|
|
mp_parse_input_kind_t parse_input_kind = MP_PARSE_SINGLE_INPUT;
|
|
|
|
|
|
|
|
if (ret == CHAR_CTRL_A) {
|
|
|
|
// change to raw REPL
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(&line);
|
|
|
|
pyexec_mode_kind = PYEXEC_MODE_RAW_REPL;
|
|
|
|
return 0;
|
|
|
|
} else if (ret == CHAR_CTRL_B) {
|
|
|
|
// reset friendly REPL
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
goto friendly_repl_reset;
|
|
|
|
} else if (ret == CHAR_CTRL_C) {
|
|
|
|
// break
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
continue;
|
|
|
|
} else if (ret == CHAR_CTRL_D) {
|
|
|
|
// exit for a soft reset
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
vstr_clear(&line);
|
|
|
|
return PYEXEC_FORCED_EXIT;
|
|
|
|
} else if (ret == CHAR_CTRL_E) {
|
|
|
|
// paste mode
|
|
|
|
mp_hal_stdout_tx_str("\r\npaste mode; Ctrl-C to cancel, Ctrl-D to finish\r\n=== ");
|
|
|
|
vstr_reset(&line);
|
|
|
|
for (;;) {
|
|
|
|
char c = mp_hal_stdin_rx_chr();
|
|
|
|
if (c == CHAR_CTRL_C) {
|
|
|
|
// cancel everything
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
goto input_restart;
|
|
|
|
} else if (c == CHAR_CTRL_D) {
|
|
|
|
// end of input
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
// add char to buffer and echo
|
|
|
|
vstr_add_byte(&line, c);
|
|
|
|
if (c == '\r') {
|
|
|
|
mp_hal_stdout_tx_str("\r\n=== ");
|
|
|
|
} else {
|
|
|
|
mp_hal_stdout_tx_strn(&c, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
parse_input_kind = MP_PARSE_FILE_INPUT;
|
|
|
|
} else if (vstr_len(&line) == 0) {
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
// got a line with non-zero length, see if it needs continuing
|
|
|
|
while (mp_repl_continue_with_input(vstr_null_terminated_str(&line))) {
|
|
|
|
vstr_add_byte(&line, '\n');
|
|
|
|
ret = readline(&line, mp_repl_get_ps2());
|
|
|
|
if (ret == CHAR_CTRL_C) {
|
|
|
|
// cancel everything
|
|
|
|
mp_hal_stdout_tx_str("\r\n");
|
|
|
|
goto input_restart;
|
|
|
|
} else if (ret == CHAR_CTRL_D) {
|
|
|
|
// stop entering compound statement
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = parse_compile_execute(&line, parse_input_kind, EXEC_FLAG_ALLOW_DEBUGGING | EXEC_FLAG_IS_REPL | EXEC_FLAG_SOURCE_IS_VSTR);
|
|
|
|
if (ret & PYEXEC_FORCED_EXIT) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif // MICROPY_REPL_EVENT_DRIVEN
|
|
|
|
#endif // MICROPY_ENABLE_COMPILER
|
|
|
|
|
|
|
|
int pyexec_file(const char *filename) {
|
|
|
|
return parse_compile_execute(filename, MP_PARSE_FILE_INPUT, EXEC_FLAG_SOURCE_IS_FILENAME);
|
|
|
|
}
|
|
|
|
|
|
|
|
int pyexec_file_if_exists(const char *filename) {
|
|
|
|
#if MICROPY_MODULE_FROZEN
|
|
|
|
if (mp_find_frozen_module(filename, NULL, NULL) == MP_IMPORT_STAT_FILE) {
|
|
|
|
return pyexec_frozen_module(filename);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
if (mp_import_stat(filename) != MP_IMPORT_STAT_FILE) {
|
|
|
|
return 1; // success (no file is the same as an empty file executing without fail)
|
|
|
|
}
|
|
|
|
return pyexec_file(filename);
|
|
|
|
}
|
|
|
|
|
|
|
|
#if MICROPY_MODULE_FROZEN
|
|
|
|
int pyexec_frozen_module(const char *name) {
|
|
|
|
void *frozen_data;
|
|
|
|
int frozen_type;
|
|
|
|
mp_find_frozen_module(name, &frozen_type, &frozen_data);
|
|
|
|
|
|
|
|
switch (frozen_type) {
|
|
|
|
#if MICROPY_MODULE_FROZEN_STR
|
|
|
|
case MP_FROZEN_STR:
|
|
|
|
return parse_compile_execute(frozen_data, MP_PARSE_FILE_INPUT, 0);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if MICROPY_MODULE_FROZEN_MPY
|
|
|
|
case MP_FROZEN_MPY:
|
|
|
|
return parse_compile_execute(frozen_data, MP_PARSE_FILE_INPUT, EXEC_FLAG_SOURCE_IS_RAW_CODE);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
default:
|
|
|
|
printf("could not find module '%s'\n", name);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if MICROPY_REPL_INFO
|
|
|
|
mp_obj_t pyb_set_repl_info(mp_obj_t o_value) {
|
|
|
|
repl_display_debugging_info = mp_obj_get_int(o_value);
|
|
|
|
return mp_const_none;
|
|
|
|
}
|
|
|
|
MP_DEFINE_CONST_FUN_OBJ_1(pyb_set_repl_info_obj, pyb_set_repl_info);
|
|
|
|
#endif
|