2016-10-10 21:21:45 +03:00
|
|
|
MicroPython port to Zephyr RTOS
|
|
|
|
|
===============================
|
|
|
|
|
|
2020-08-28 16:42:32 +10:00
|
|
|
This is a work-in-progress port of MicroPython to Zephyr RTOS
|
2016-10-10 21:21:45 +03:00
|
|
|
(http://zephyrproject.org).
|
|
|
|
|
|
2022-09-16 13:17:05 -05:00
|
|
|
This port requires Zephyr version v3.7.0, and may also work on higher
|
2020-08-28 16:42:32 +10:00
|
|
|
versions. All boards supported
|
2017-05-12 22:05:07 +03:00
|
|
|
by Zephyr (with standard level of features support, like UART console)
|
|
|
|
|
should work with MicroPython (but not all were tested).
|
2016-10-10 21:21:45 +03:00
|
|
|
|
2016-10-28 21:51:18 +03:00
|
|
|
Features supported at this time:
|
|
|
|
|
|
|
|
|
|
* REPL (interactive prompt) over Zephyr UART console.
|
2022-08-17 16:18:31 +10:00
|
|
|
* `time` module for time measurements and delays.
|
2020-08-28 16:42:32 +10:00
|
|
|
* `machine.Pin` class for GPIO control, with IRQ support.
|
2019-03-28 16:12:20 +02:00
|
|
|
* `machine.I2C` class for I2C control.
|
2021-06-14 16:57:29 -05:00
|
|
|
* `machine.SPI` class for SPI control.
|
2022-08-17 16:18:31 +10:00
|
|
|
* `socket` module for networking (IPv4/IPv6).
|
2016-10-28 21:51:18 +03:00
|
|
|
* "Frozen modules" support to allow to bundle Python modules together
|
|
|
|
|
with firmware. Including complete applications, including with
|
|
|
|
|
run-on-boot capability.
|
2020-08-28 16:42:32 +10:00
|
|
|
* virtual filesystem with FAT and littlefs formats, backed by either
|
|
|
|
|
DiskAccess or FlashArea (flash map).
|
2016-10-28 21:51:18 +03:00
|
|
|
|
|
|
|
|
Over time, bindings for various Zephyr subsystems may be added.
|
2016-10-10 21:21:45 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Building
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
Follow to Zephyr web site for Getting Started instruction of installing
|
|
|
|
|
Zephyr SDK, getting Zephyr source code, and setting up development
|
|
|
|
|
environment. (Direct link:
|
2020-08-28 16:42:32 +10:00
|
|
|
https://docs.zephyrproject.org/latest/getting_started/index.html).
|
2016-10-10 21:21:45 +03:00
|
|
|
You may want to build Zephyr's own sample applications to make sure your
|
|
|
|
|
setup is correct.
|
|
|
|
|
|
2020-08-28 16:42:32 +10:00
|
|
|
If you already have Zephyr installed but are having issues building the
|
|
|
|
|
MicroPython port then try installing the correct version of Zephyr via:
|
2016-10-10 21:21:45 +03:00
|
|
|
|
2022-09-16 13:17:05 -05:00
|
|
|
$ west init zephyrproject -m https://github.com/zephyrproject-rtos/zephyr --mr v3.7.0
|
2020-08-28 16:42:32 +10:00
|
|
|
|
|
|
|
|
Alternatively, you don't have to redo the Zephyr installation to just
|
|
|
|
|
switch from master to a tagged release, you can instead do:
|
|
|
|
|
|
|
|
|
|
$ cd zephyrproject/zephyr
|
2022-09-16 13:17:05 -05:00
|
|
|
$ git checkout v3.7.0
|
2020-08-28 16:42:32 +10:00
|
|
|
$ west update
|
|
|
|
|
|
|
|
|
|
With Zephyr installed you may then need to configure your environment,
|
|
|
|
|
for example by sourcing `zephyrproject/zephyr/zephyr-env.sh`.
|
|
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
Once Zephyr is ready to use you can build the MicroPython port just like any
|
|
|
|
|
other Zephyr application. You can do this anywhere in your file system, it does
|
|
|
|
|
not have to be in the `ports/zephyr` directory. Assuming you have cloned the
|
|
|
|
|
MicroPython repository into your home directory, you can build the Zephyr port
|
|
|
|
|
for a frdm_k64f board like this:
|
2020-08-28 16:42:32 +10:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
$ west build -b frdm_k64f ~/micropython/ports/zephyr
|
2016-10-10 21:21:45 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
To build for QEMU instead:
|
|
|
|
|
|
|
|
|
|
$ west build -b qemu_x86 ~/micropython/ports/zephyr
|
|
|
|
|
|
2024-06-28 09:34:59 +02:00
|
|
|
To build any board with the `_thread` module enabled,
|
|
|
|
|
add `-DOVERLAY_CONFIG=thread.conf`, for instance:
|
|
|
|
|
|
|
|
|
|
$ west build -b frdm_k64f ~/micropython/ports/zephyr -DOVERLAY_CONFIG=thread.conf
|
|
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
Consult the Zephyr documentation above for the list of
|
2020-08-28 16:42:32 +10:00
|
|
|
supported boards. Board configuration files appearing in `ports/zephyr/boards/`
|
|
|
|
|
correspond to boards that have been tested with MicroPython and may have
|
|
|
|
|
additional options enabled, like filesystem support.
|
2016-10-10 21:21:45 +03:00
|
|
|
|
|
|
|
|
Running
|
|
|
|
|
-------
|
|
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
To flash the resulting firmware to your board:
|
2016-10-10 21:21:45 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
$ west flash
|
2016-10-10 21:21:45 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
Or, to flash it to your board and start a gdb debug session:
|
2017-02-01 21:23:29 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
$ west debug
|
2017-02-01 21:23:29 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
To run the resulting firmware in QEMU (for BOARDs like qemu_x86,
|
|
|
|
|
qemu_cortex_m3):
|
2017-02-01 21:23:29 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
$ west build -t run
|
2016-10-28 21:51:18 +03:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
Networking is enabled with the default configuration, so you need to follow
|
|
|
|
|
instructions in
|
|
|
|
|
https://docs.zephyrproject.org/latest/guides/networking/qemu_setup.html#networking-with-qemu
|
|
|
|
|
to setup the host side of TAP/SLIP networking. If you get an error like:
|
2020-08-28 16:42:32 +10:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
could not connect serial device to character backend 'unix:/tmp/slip.sock'
|
2020-08-28 16:42:32 +10:00
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
it's a sign that you didn't follow the instructions above. If you would like
|
|
|
|
|
to just run it quickly without extra setup, see "minimal" build below.
|
2016-10-28 21:51:18 +03:00
|
|
|
|
|
|
|
|
Quick example
|
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
To blink an LED:
|
|
|
|
|
|
|
|
|
|
import time
|
|
|
|
|
from machine import Pin
|
|
|
|
|
|
zephyr: Allow using devicetree node labels to construct machine objects.
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
2024-08-05 12:58:36 -05:00
|
|
|
LED = Pin(("gpiob", 21), Pin.OUT)
|
2016-10-28 21:51:18 +03:00
|
|
|
while True:
|
|
|
|
|
LED.value(1)
|
|
|
|
|
time.sleep(0.5)
|
|
|
|
|
LED.value(0)
|
|
|
|
|
time.sleep(0.5)
|
|
|
|
|
|
|
|
|
|
The above code uses an LED location for a FRDM-K64F board (port B, pin 21;
|
zephyr: Allow using devicetree node labels to construct machine objects.
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
2024-08-05 12:58:36 -05:00
|
|
|
following Zephyr conventions port are identified by their devicetree node
|
|
|
|
|
label. You will need to adjust it for another board (using board's reference
|
|
|
|
|
materials). To execute the above sample, copy it to clipboard, in MicroPython
|
|
|
|
|
REPL enter "paste mode" using Ctrl+E, paste clipboard, press Ctrl+D to finish
|
|
|
|
|
paste mode and start execution.
|
2016-11-05 00:22:37 +03:00
|
|
|
|
2020-08-28 16:42:32 +10:00
|
|
|
To respond to Pin change IRQs, on a FRDM-K64F board run:
|
|
|
|
|
|
|
|
|
|
from machine import Pin
|
|
|
|
|
|
zephyr: Allow using devicetree node labels to construct machine objects.
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
2024-08-05 12:58:36 -05:00
|
|
|
SW2 = Pin(("gpioc", 6), Pin.IN)
|
|
|
|
|
SW3 = Pin(("gpioa", 4), Pin.IN)
|
2020-08-28 16:42:32 +10:00
|
|
|
|
|
|
|
|
SW2.irq(lambda t: print("SW2 changed"))
|
|
|
|
|
SW3.irq(lambda t: print("SW3 changed"))
|
|
|
|
|
|
|
|
|
|
while True:
|
|
|
|
|
pass
|
|
|
|
|
|
2019-03-28 16:12:20 +02:00
|
|
|
Example of using I2C to scan for I2C slaves:
|
|
|
|
|
|
|
|
|
|
from machine import I2C
|
|
|
|
|
|
zephyr: Allow using devicetree node labels to construct machine objects.
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
2024-08-05 12:58:36 -05:00
|
|
|
i2c = I2C("i2c0")
|
2019-03-28 16:12:20 +02:00
|
|
|
i2c.scan()
|
|
|
|
|
|
2021-06-14 16:57:29 -05:00
|
|
|
Example of using SPI to write a buffer to the MOSI pin:
|
|
|
|
|
|
|
|
|
|
from machine import SPI
|
|
|
|
|
|
zephyr: Allow using devicetree node labels to construct machine objects.
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
2024-08-05 12:58:36 -05:00
|
|
|
spi = SPI("spi0")
|
2021-06-14 16:57:29 -05:00
|
|
|
spi.init(baudrate=500000, polarity=1, phase=1, bits=8, firstbit=SPI.MSB)
|
|
|
|
|
spi.write(b'abcd')
|
|
|
|
|
|
2016-11-05 00:22:37 +03:00
|
|
|
|
|
|
|
|
Minimal build
|
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
MicroPython is committed to maintain minimal binary size for Zephyr port
|
|
|
|
|
below 128KB, as long as Zephyr project is committed to maintain stable
|
|
|
|
|
minimal size of their kernel (which they appear to be). Note that at such
|
|
|
|
|
size, there is no support for any Zephyr features beyond REPL over UART,
|
2017-05-12 22:05:07 +03:00
|
|
|
and only very minimal set of builtin Python modules is available. Thus,
|
|
|
|
|
this build is more suitable for code size control and quick demonstrations
|
|
|
|
|
on smaller systems. It's also suitable for careful enabling of features
|
|
|
|
|
one by one to achieve needed functionality and code size. This is in the
|
2017-03-12 23:41:19 +03:00
|
|
|
contrast to the "default" build, which may get more and more features
|
|
|
|
|
enabled over time.
|
2016-11-05 00:22:37 +03:00
|
|
|
|
|
|
|
|
To make a minimal build:
|
|
|
|
|
|
2020-10-11 13:11:31 -05:00
|
|
|
$ west build -b qemu_x86 ~/micropython/ports/zephyr -- -DCONF_FILE=prj_minimal.conf
|
2017-02-01 21:23:29 +03:00
|
|
|
|
|
|
|
|
To run a minimal build in QEMU without requiring TAP networking setup
|
2020-10-11 13:11:31 -05:00
|
|
|
run the following after you built an image with the previous command:
|
|
|
|
|
|
|
|
|
|
$ west build -t run
|
2017-02-01 21:23:29 +03:00
|
|
|
|