zephyr: Upgrade to Zephyr v3.7.0. #9335
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #9335 +/- ##
=======================================
Coverage 98.57% 98.57%
=======================================
Files 164 164
Lines 21336 21336
=======================================
Hits 21031 21031
Misses 305 305 ☔ View full report in Codecov by Sentry. |
663e6f3 to
ba78e4b
Compare
docs/zephyr/quickref.rst
Outdated
| @@ -36,7 +36,10 @@ Use the :ref:`machine.Pin <machine.Pin>` class:: | |||
|
|
|||
| from machine import Pin | |||
|
|
|||
| pin = Pin(("GPIO_1", 21), Pin.IN) # create input pin on GPIO1 | |||
| gpio1 = "gpio@400ff040" # GPIO1 device name | |||
| gpio2 = "gpio@400ff080" # GPIO2 device name | |||
There was a problem hiding this comment.
This seems quite.... un-user-friendly, to know the address. Is there a better solution? How do other Zephyr projects handle this? Maybe in the device tree / overlay we can have an alias?
There was a problem hiding this comment.
As @jimmo says below, he'll look into this.
There was a problem hiding this comment.
Please have a look at #10859
|
Thanks @MaureenHelm !! I think we're going to need to come up with a solution for the issue discussed in #9115 before merging this, i.e. we need to make it possible to instantiate pins and other peripherals without needing to know the register base addresses. I will investigate. |
ba78e4b to
c67092d
Compare
|
Code size report: |
|
Adding a few thoughts to this discussion: we might be able to use some of the build files generated by Zephyr to solve this problem. For example, there is a This can be parsed by a Python script to generate more friendly names ( There's also The point is that we probably need this additional processing step and it needs to be plugged in into Zephyr's cmake machinery. I'm not sure how to do this yet, but I'm going to look deeper into it, because I don't see a better way to fix this. |
c67092d to
4fcc267
Compare
4fcc267 to
548cebf
Compare
|
Rebased and updated for Zephyr v3.5.0 |
548cebf to
eecb0b4
Compare
|
Rebased and updated for Zephyr v3.6.0 |
docs/zephyr/quickref.rst
Outdated
| @@ -36,7 +36,10 @@ Use the :ref:`machine.Pin <machine.Pin>` class:: | |||
|
|
|||
| from machine import Pin | |||
|
|
|||
| pin = Pin(("GPIO_1", 21), Pin.IN) # create input pin on GPIO1 | |||
| gpiob = "gpiob" # GPIO port B devicetree node label | |||
| gpioc = "gpioc" # GPIO port C devicetree node label | |||
There was a problem hiding this comment.
Is it worth defining variables like this? The original example code had the strings written inline in the Pin constructor, and I think that's slightly better from an example point of view because it makes it easy to just cut-and-paste a single line and it should just work. Eg:
pin = Pin(("gpiob", 21), Pin.IN)That's obvious at a glance just at that line how to specify a pin name.
ports/zephyr/machine_i2c.c
Outdated
| dev = device_get_by_dt_nodelabel(dev_name); | ||
| } | ||
| #endif | ||
|
|
There was a problem hiding this comment.
I suggest making a general helper function for this bit:
const struct device *zephyr_device_find(mp_obj_t name) {
const char *dev_name = mp_obj_str_get_str(name);
const struct device *dev = device_get_binding(dev_name);
#ifdef CONFIG_DEVICE_DT_METADATA
if (dev == NULL) {
dev = device_get_by_dt_nodelabel(dev_name);
}
#endif
if (dev == NULL) {
#if MICROPY_ERROR_REPORTING <= MICROPY_ERROR_REPORTING_TERSE
mp_raise_ValueError(MP_ERROR_TEXT("device not found"));
#else
mp_raise_msg_varg(&mp_type_ValueError, MP_ERROR_TEXT("device %s not found"), dev_name);
#endif
}
return dev;
}That can be used in quite a few places in this PR.
7e8563a to
987d5d0
Compare
|
Amazing! Looking forward for this to be merged :-) |
|
Anything else needed to get this merged? |
Zephyr v3.1.0 moved all public headers to include/zephyr. Updates a few Zephyr include paths that were missed in 4fd54a4. Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Zephyr v3.2.0 deprecated include/zephyr/zephyr.h in favor of include/zephyr/kernel.h since it only included that header. Signed-off-by: Maureen Helm <maureen.helm@intel.com>
|
@MaureenHelm If you don't mind, during merge I would squash some of the commits here, eg it probably needs only one commit to update the Docker image and SDK in |
Ok |
Zephyr v3.2.0 deprecated the devicetree label property as a base property, which had been used as the device name string for device_get_binding(). The device name string is now the devicetree node name appended with its unit-address. Update Zephyr port documentation to reflect this change. Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Zephyr v3.2.0 deprecated FLASH_AREA macros in favor of FIXED_PARTITION macros, using node labels instead of node label properties to reference flash storage partitions. Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Zephyr v3.4.0 changed the declaration of the main function to return an int to allow building Zephyr without the -ffreestanding compiler flag. Signed-off-by: Maureen Helm <maureen.helm@analog.com>
Zephyr v3.4.0 changed the SPI chip select from a pointer to a struct member to allow using the existing SPI dt-spec macros in C++. Signed-off-by: Maureen Helm <maureen.helm@analog.com>
Upgrades CI to use the latest versions of the Zephyr docker image and Zephyr SDK. Signed-off-by: Maureen Helm <maureen.helm@analog.com>
Updates the Zephyr port build instructions and CI to use the latest Zephyr release tag. Tested on frdm_k64f. Signed-off-by: Maureen Helm <maureen.helm@analog.com>
987d5d0 to
d2e6021
Compare
|
I've rebased this on latest master, and squashed some of the commits, and force-pushed to this branch. I was ready to merge it but the CI is not happy: Looks like the CI VM itself ran out of disk space?? That's only when building boards latter in the test, so maybe we can clean up previous builds to free up space? There's also the following warning which I think needs to be fixed: |
Refactors Zephyr device lookup operations into a common helper function to reduce boilerplate code that was repeated in multiple modules. Suggested-by: Damien George <damien@micropython.org> Signed-off-by: Maureen Helm <maureen.helm@analog.com>
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>
d2e6021 to
a9803f4
Compare
d0dc46c to
514c43d
Compare
|
I fixed the CI out-of-space issue by using https://github.com/marketplace/actions/free-disk-space-ubuntu in the zephyr workflow. |
The zephyr builds take up quite a lot of space. Signed-off-by: Damien George <damien@micropython.org>
ae862fd to
1291718
Compare
|
Merged! Thanks again @MaureenHelm for keeping this PR up-to-date. |
Fixed
Thanks! |
Updates the Zephyr port build instructions and CI to use the latest
Zephyr release tag.
Tested on frdm_k64f.
In draft status until the Zephyr release is finalized (currently in release candidate / stabilization phase).Zephyr v3.2.0 was released on Sep 30 2022.
Zephyr v3.3.0 was released on Feb 19 2023.
Zephyr v3.4.0 was released on Jun 16 2023.
Zephyr v3.5.0 was released on Oct 20 2023.
Zephyr v3.6.0 was released on Feb 23 2024.
Zephyr v3.7.0 was released on Jul 26 2024.
Fixes #9115