Improvements are:
2 ctrl-C's are now needed to truly kill running script on pyboard, so
make CDC interface allow multiple ctrl-C's through at once (ie sending
b'\x03\x03' to pyboard now counts as 2 ctrl-C's).
ctrl-C in friendly-repl can now stop multi-line input.
In raw-repl mode, use ctrl-D to indicate end of running script, and also
end of any error message. Thus, output of raw-repl is always at least 2
ctrl-D's and it's much easier to parse.
pyboard.py is now a bit faster, handles exceptions from pyboard better
(prints them and exits with exit code 1), prints out the pyboard output
while the script is running (instead of waiting till the end), and
allows to follow the output of a previous script when run with no
arguments.
This allows to implement KeyboardInterrupt on unix, and a much safer
ctrl-C in stmhal port. First ctrl-C is a soft one, with hope that VM
will notice it; second ctrl-C is a hard one that kills anything (for
both unix and stmhal).
One needs to check for a pending exception in the VM only for jump
opcodes. Others can't produce an infinite loop (infinite recursion is
caught by stack check).
There is a lot potential in compress bytecodes and make more use of the
coding space. This patch introduces "multi" bytecodes which have their
argument included in the bytecode (by addition).
UNARY_OP and BINARY_OP now no longer take a 1 byte argument for the
opcode. Rather, the opcode is included in the first byte itself.
LOAD_FAST_[0,1,2] and STORE_FAST_[0,1,2] are removed in favour of their
multi versions, which can take an argument between 0 and 15 inclusive.
The majority of LOAD_FAST/STORE_FAST codes fit in this range and so this
saves a byte for each of these.
LOAD_CONST_SMALL_INT_MULTI is used to load small ints between -16 and 47
inclusive. Such ints are quite common and now only need 1 byte to
store, and now have much faster decoding.
In all this patch saves about 2% RAM for typically bytecode (1.8% on
64-bit test, 2.5% on pyboard test). It also reduces the binary size
(because bytecodes are simplified) and doesn't harm performance.
This saves a lot of RAM for 2 reasons:
1. For functions that don't have default values, var args or var kw
args (which is a large number of functions in the general case), the
mp_obj_fun_bc_t type now fits in 1 GC block (previously needed 2 because
of the extra pointer to point to the arg_names array). So this saves 16
bytes per function (32 bytes on 64-bit machines).
2. Combining separate memory regions generally saves RAM because the
unused bytes at the end of the GC block are saved for 1 of the blocks
(since that block doesn't exist on its own anymore). So generally this
saves 8 bytes per function.
Tested by importing lots of modules:
- 64-bit Linux gave about an 8% RAM saving for 86k of used RAM.
- pyboard gave about a 6% RAM saving for 31k of used RAM.
TIM2_CH1_ETR is really bundling 2 functions to the same pin:
TIM2_CH1 (where its used as a channel)
TIM2_ETR (where iss used as an external trigger).
I fixed most of these a while back, but it looks like I missed this one.
Also make cc3k.send and cc3k.recv independent functions (not wrapped by
stream write/read). Also make wiznet5k.recv more memory efficient.
This might address issue #920.
UART object now uses a stream-like interface: read, readall, readline,
readinto, readchar, write, writechar.
Timeouts are configured when the UART object is initialised, using
timeout and timeout_char keyword args.
The object includes optional read buffering, using interrupts. You can set
the buffer size dynamically using read_buf_len keyword arg. A size of 0
disables buffering.
mode argument is used to assert it works
encoding argument is used to make sure CPython uses the correct encoding
as it does not automatically use utf-8
This makes open() and _io.FileIO() more CPython compliant.
The mode kwarg is fully iplemented.
The encoding kwarg is allowed but not implemented; mainly to allow
the tests to specify encoding for CPython, see #874
When loading the ELF binary to the board with a debugger, the debugger
needs to know at which point to start executing the code. Currently the
entry point defaults to the start of the .text section.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
This fixed an issue with a certain SD card sometimes not initialising
first time round. See issue #822 for related, and thanks to
@iabdalkader for the idea.
