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.
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.
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.
uwTick can only change in the SysTick IRQ so this IRQ function does not
need to take special care with this variable. It's important to make
this IRQ function as efficient as possible.
Using SysTick to do the counting and dispatch of the flash storage idle
handler is more efficient than requiring a dedicated hardware timer.
No new counter is needed, just the existing uwTick variable. The
processing is not actually done in the SysTick IRQ, it is deferred to
the flash IRQ (which runs at lower priority).
- add mp_int_t/mp_uint_t typedefs in mpconfigport.h
- fix integer suffixes/formatting in mpconfig.h and mpz.h
- use MICROPY_NLR_SETJMP=1 in Makefile since the current nlrx64.S
implementation causes segfaults in gc_free()
- update README
The BSD stuff is a copy from the unix makefile but at least there it
makes some sense, a windows makefile on BSD doesn't.
The -lmman flag is probably for mmap functions but there is no other build
support for it on windows so just that flag won't cut it anyway.
Dave Hylands
Paul Sokolovsky
Damien George
fabien.lementec
Ryan Shaw
danicampora
Tobias Badertscher
stijn