Supports hard and soft interrupts. In the current implementation, soft
interrupt callbacks will only be called when the VM is executing, ie they
will not be called during a blocking kernel call like k_msleep. And the
behaviour of hard interrupt callbacks will depend on the underlying device,
as well as the amount of ISR stack space.
Soft and hard interrupts tested on frdm_k64f and nucleo_f767zi boards.
Signed-off-by: Damien George <damien@micropython.org>
The zephyr build system supports merging application-level board
configurations, so there is no need to reproduce this functionality in
MicroPython.
If CONF_FILE is not explicitly set, then the zephyr build system looks for
prj.conf in the application directory. Therefore we rename the MicroPython
prj_base.conf to prj.conf.
Furthermore, if the zephyr build system finds boards/$(BOARD).conf in the
application directory, it merges that configuration with prj.conf.
Therefore we rename all the MicroPython board .conf files and move them
into a boards/ directory.
The minimal configuration, prj_minimal.conf, is left in the application
directory because it is used as an explicitly set CONF_FILE in
make-minimal.
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.
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.
Zephyr removed the build target syscall_macros_h_target in commit
f4adf107f31674eb20881531900ff092cc40c07f. Removes reference from
MicroPython to fix build errors in the zephyr port.
This change is not compatible with zephyr v2.1 or earlier. It will be
compatible with Zephyr v2.2 when released.
Adds support for hardware i2c to the zephyr port. Similar to other ports
such as stm32 and nrf, we only implement the i2c protocol functions
(readfrom and writeto) and defer memory operations (readfrom_mem,
readfrom_mem_into, and writeto_mem) to the software i2c implementation.
This may need to change in the future because zephyr is considering
deprecating its i2c_transfer function in favor of i2c_write_read; in this
case we would probably want to implement the memory operations directly
using i2c_write_read.
Tested with the accelerometer on frdm_k64f and bbc_microbit boards.
This time hopefully should work reliably, using make $(wildcard) function,
which in this case either expands to existing prj_$(BOARD).conf file, or to
an empty string for non-existing one.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
