Browse Source
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>pull/6527/head
Damien George
4 years ago
1 changed files with 118 additions and 0 deletions
Loading…
Reference in new issue