As set by signal handler. This assumes that exception will be raised
somewhere else, which so far doesn't happen for single function call.
Still, it makes sense to handle that in some common place.

In non-blocking mode (timeout=0), uart.write() can now transmit all of its
data without raising an exception.  uart.read() also works correctly in
this mode.

As part of this patch, timout_char now has a minimum value which is long
enough to transfer 1 character.

Addresses issue #1533.

To use, put the following in mpconfigport.h:

    #define MICROPY_OBJ_REPR (MICROPY_OBJ_REPR_D)
    #define MICROPY_FLOAT_IMPL (MICROPY_FLOAT_IMPL_DOUBLE)
    typedef int64_t mp_int_t;
    typedef uint64_t mp_uint_t;
    #define UINT_FMT "%llu"
    #define INT_FMT "%lld"

Currently does not work with native emitter enabled.

This allows the mp_obj_t type to be configured to something other than a
pointer-sized primitive type.

This patch also includes additional changes to allow the code to compile
when sizeof(mp_uint_t) != sizeof(void*), such as using size_t instead of
mp_uint_t, and various casts.

The GC works with concrete pointers and so the types should reflect this.

THis is required to deal well with signals, signals being the closest
analogue of hardware interrupts for POSIX. This is also CPython 3.5
compliant behavior (PEP 475).

The main problem implementing this is to figure out how much time was
spent in waiting so far/how much is remaining. It's well-known fact that
Linux updates select()'s timeout value when returning with EINTR to the
remaining wait time. Here's what POSIX-based standards say about this:
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/pselect.html):

"Upon successful completion, the select() function may modify the object
pointed to by the timeout argument."

I.e. it allows to modify timeout value, but doesn't say how exactly it is
modified. And actually, it allows such modification only "upon successful
completion", which returning with EINTR error hardly is.

POSIX also allows to request automatic EINTR restart for system calls using
sigaction call with SA_RESTART flag, but here's what the same document says
about it:

"If SA_RESTART has been set for the interrupting signal, it is
implementation-defined whether the function restarts or returns with
[EINTR]."

In other words, POSIX doesn't leave room for both portable and efficient
handling of this matter, so the code just allows to manually select
Linux-compatible behavior with MICROPY_SELECT_REMAINING_TIME option,
or otherwise will just raise OSError. When systems with non-Linux behavior
are found, they can be handled separately.

With these you can now do things like:

stm.mem32[0x20000000] = 0x80000000

and read 32-bit values. You can also read all the way to the end
of memory using either stm.mem32[0xfffffffc] or stm.mem32[-4].

IRQs shouldn't use mem32 at all since they'd fail if the top 2 bits
weren't equal, so IRQs should be using 16-bit I/O.

The STMCube examples define both USE_USB_HS and USE_USB_HS_IN_FS when they
use the HS in FS mode.

The STM32F401 doesn't have a USB_HS at all, so the USB_OTG_HS instance
doesn't even exist.

Define MICROPY_NO_ALLOCA=1 and memory will be allocated from heap instead
and freed by garbage collection.

The UARTs have no FIFOs, so if interrupts are disabled
for more than a character time (10 usec at 1 Mbit/sec)
then characters get dropped.

The overhead for handling a UART ISR is about 0.5 usec,
so even at baud rates of 1 Mbit/sec this only corresponds
to about 5% of the CPU. Lower baud rates will have less
of an impact.

Based on vendor API documentation, untested on real hardware.

Unconditionally wait for MicroPython banner. On overloaded systems, when
using emulators, etc. initial executable startup may take more than 20ms.