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).
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.
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>