And rename it to mp_obj_cast_to_native_base() to indicate this. This
allows users of this function to easily support native and native-subclass
objects in the same way (by just passing the object through this function).
Since commit 3aab54bf43 this piece of code is
no longer needed because the top-level function mp_obj_equal_not_equal()
now handles the case of user types, and will never call tuple's binary_op
function with MP_BINARY_OP_EQUAL and a non-tuple on the RHS.
Only the "==" operator was tested by the test suite in for such arguments.
Other comparison operators like "<" take a different path in the code so
need to be tested separately.
If the built-in input() is enabled (which it is by default) then it needs
some form of readline, so supply it with one when MICROPY_USE_READLINE=0.
Fixes issue #5658.
Follow up to recent commit ad7213d3c3, the
name "varg2" is misleading, vlist describes better that the argument is a
va_list. This name also matches CircuitPython, which already has such
helper functions.
This changes the signal used to trigger garbage collection from SIGUSR1 to
SIGRTMIN + 5. SIGUSR1 is quite common compared to SIGRTMIN (measured by
google search results) and is more likely to conflict with libraries that
may use the same signal.
POSIX specifies that there are at least 8 real-time signal so 5 was chosen
as a "random" number to further avoid potential conflict with libraries
that may use SIGRTMIN or SIGRTMAX.
Also, if we ever have a `usignal` module, it would be nice to leave SIGUSR1
and SIGUSR2 free for user programs.
The "random" module no longer uses the hardware RNG (the extmod version of
this module has a pseudo-random number generator), so the config option
MICROPY_PY_RANDOM_HW_RNG is no longer meaningful. This commit replaces it
with MICROPY_HW_ENABLE_RNG, which controls whether the hardware RNG is
included in the build.
The install target is current broken when PROG is used to override the
default executable name. This fixes it by removing the redundant TARGET
variable and uses PROG directly instead.
The install and uninstall targets are also moved to the common unix
Makefile so that all variants can be installed in the same way.
Currently it is not possible to override PREFIX when installing micropython
using the makefile. It is common practice to be able to run something like
this:
$ make install PREFIX=/usr DESTDIR=/tmp/staging
This fixes such usage.
These addresses were initially chosen to match the nRF24 Arduino library
examples but they are byte-reversed. So change them to be on-air
compatible with the Arduino library.
Also, the data sheet for the nRF24 says that RX data pipes 1-5 must share
the same top 32-bits, and must differ only in the LSbyte. The addresses
used here (while correct because they are on TX pipe and RX pipe 0) are
misleading in this sense, because it looks like they were chosen to share
the top 32-bits per the datasheet.
This provides a more consistent C-level API to raise exceptions, ie moving
away from nlr_raise towards mp_raise_XXX. It also reduces code size by a
small amount on some ports.
The default value for MICROPYPATH used in unix/main.c is
"~/.micropython/lib:/usr/lib/micropython" which has 2 problems when used in
the Windows port:
- it has a ':' as path separator but the port uses ';' so the entire string
is effectively discarded since it gets interpreted as a single path which
doesn't exist
- /usr/lib/micropython is not a valid path in a standard Windows
environment
Override the value with a suitable default.
If the exception doesn't need printf-style formatting then calling
mp_raise_msg is more efficient. Also shorten exception messages to match
style in core and other ports.
Both bool and namedtuple will check against other types for equality; int,
float and complex for bool, and tuple for namedtuple. So to make them work
after the recent commit 3aab54bf43 they would
need MP_TYPE_FLAG_NEEDS_FULL_EQ_TEST set. But that makes all bool and
namedtuple equality checks less efficient because mp_obj_equal_not_equal()
could no longer short-cut x==x, and would need to try __ne__. To improve
this, this commit splits the MP_TYPE_FLAG_NEEDS_FULL_EQ_TEST flags into 3
separate flags to give types more fine-grained control over how their
equality behaves. These new flags are then used to fix bool and namedtuple
equality.
Fixes issue #5615 and #5620.
This fix can be demonstrated by the following:
b = bytearray(32)
f = framebuf.FrameBuffer(b, 32, 8, framebuf.MONO_HLSB)
f.pixel(0, 0, 1)
print('MONO_HLSB', hex(b[0]))
b = bytearray(32)
f = framebuf.FrameBuffer(b, 32, 8, framebuf.MONO_HMSB)
f.pixel(0, 0, 1)
print('MONO_HMSB', hex(b[0]))
Outcome:
MONO_HLSB 0x80
MONO_HMSB 0x1
It's not needed. The C integer implicit promotion rules mean that the
uint8_t of the incoming character is promoted to a (signed) int, matching
the type of interrupt_char. Thus the uint8_t incoming character can never
be equal to -1 (the value of interrupt_char that indicate that interruption
is disabled).
The mp_keyboard_interrupt() function does exactly what is needed here, and
using it gets ctrl-C working when MICROPY_ENABLE_SCHEDULER is enabled on
these ports (and MICROPY_ASYNC_KBD_INTR is disabled).
This is a more logical place to clear the KeyboardInterrupt traceback,
right before it is set as a pending exception. The clearing is also
optimised from a function call to a simple store of NULL.
It was originally in IRAM due to the linker script specification, but
since the function moved from lib/utils/interrupt_char.c to py/scheduler.c
it needs to be put back in IRAM.
Functions like mp_keyboard_interrupt() may need to be called from an IRQ
handler and may need to be in a special memory section, so provide a
generic wrapping macro for a port to do this. The macro name is chosen to
be MICROPY_WRAP_<function name in uppercase> so that (in the future with
more wrappers) each function could potentially be handled separately.
This function is tightly coupled to the state and behaviour of the
scheduler, and is a core part of the runtime: to schedule a pending
exception. So move it there.
Pending exceptions would otherwise be handled later on where there may not
be an NLR handler in place.
A similar fix is also made to the unix port's REPL handler.
Fixes issues #4921 and #5488.
Previous behaviour is when this argument is set to "true", in which case
the function will raise any pending exception. Setting it to "false" will
cancel any pending exception.
Enables the littlefs (v1 and v2) filesystems in the zephyr port.
Example usage with the internal flash on the reel_board or the
rv32m1_vega_ri5cy board:
import os
from zephyr import FlashArea
bdev = FlashArea(FlashArea.STORAGE, 4096)
os.VfsLfs2.mkfs(bdev)
os.mount(bdev, '/flash')
with open('/flash/hello.txt','w') as f:
f.write('Hello world')
print(open('/flash/hello.txt').read())
Things get a little trickier with the frdm_k64f due to the micropython
application spilling into the default flash storage partition defined
for this board. The zephyr build system doesn't enforce the flash
partitioning when mcuboot is not enabled (which it is not for
micropython). For now we can demonstrate that the littlefs filesystem
works on frdm_k64f by constructing the FlashArea block device on the
mcuboot scratch partition instead of the storage partition. Do this by
replacing the FlashArea.STORAGE constant above with the value 4.
Introduces a new zephyr.FlashArea class that uses the zephyr flash map
api to implement the uos.AbstractBlockDev protocol. The flash driver is
enabled on the frdm_k64f board, reel_board, and rv32m1_vega_ri5cy board.
The standard and extended block device protocols are both supported,
therefore this class can be used with file systems like littlefs which
require the extended interface.
Enables the fatfs filesystem in the zephyr port.
Example usage with an SD card on the mimxrt1050_evk board:
import zephyr, os
bdev = zephyr.DiskAccess('SDHC')
os.VfsFat.mkfs(bdev)
os.mount(bdev, '/sd')
with open('/sd/hello.txt','w') as f:
f.write('Hello world')
print(open('/sd/hello.txt').read())
Introduces a new zephyr.DiskAccess class that uses the zephyr disk
access api to implement the uos.AbstractBlockDev protocol. This can be
used with any type of zephyr disk access driver, which currently
includes SDHC, RAM, and FLASH implementations. The SDHC driver is
enabled on the mimxrt1050_evk board.
Only the standard block device protocol (without the offset parameter)
can be supported with the zephyr disk access api, therefore this class
cannot be used with file systems like littlefs which require the
extended interface. In the future it may be possible to implement the
extended interface in a new class using the zephyr flash api.
Damien George
Jim Mussared
David Lechner
Andrew Leech
Thomas Friebel
David Lechner
cccc
Peter Hinch
Thorsten von Eicken
stijn
Yonatan Goldschmidt
Maureen Helm