This gets CDC+HID working on Windows, since it needs a different PID for
a different USB configuration.

Thanks to tmbinc and dhylands.

This should be pretty compliant with CPython, except perhaps for some
corner cases to do with globals/locals context.

Addresses issue #879.

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.

For kilobytes and megabytes respectively.

This is so it's compatible with Windows.

Also change HID device from keyboard to mouse (should have been mouse
all along).

In unix port, mem_info(1) now prints pretty GC alloc table.

Also move the raw bytecode printing code from emitglue to mp_bytecode_print.

While extension to file.readinto() definition of CPython, the additional arg
is similar to what in CPython available in socket.recv_into().

Addresses issue #921.

Addresses issue #927.

You can do:

make USE_PYDFU=1 deploy

to use pydfu.py

It's purpose is for internal errors that are not catastrophic (ie not as
bad as RuntimeError).  Since we don't use it, we don't need it.

This allows you to register ExtInt on the MMA interrupt pin.

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.

There is no need, since we don't (currently) use the value.

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.

stmhal: Set entry point for ELF binary debugging

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.