"ValueError: invalid port" on machine module due to devicetree property deprecation in zephyr (?)

[jaenrig-ifx]

Hi @MaureenHelm,
Hi @dpgeorge,

After going a little bit through the commit history of the zephyr port, I believe you might be the most familiar with this topic 🔧.

When trying to instantiate Pin (and probably other machine module classes) there is no way to provide a valid port.

For example, when in REPL mode:

*** Booting Zephyr OS build deb243fcf94e  ***
MicroPython deb243fcf9-dirty on 2022-08-26; zephyr-cy8cproto_062_4343w with unknown-cpu
>>> from machine import Pin
>>> pin = Pin(("LED_0",7), Pin.OUT)                                                         
Traceback (most recent call last):                                                          
  File "<stdin>", line 1, in <module>                                                       
ValueError: invalid port 

I have tried with a couple boards: nrf52840DK and CY8CPROTO_062_4343W. The latest is currently being added to zephyr (work in progress). That combined with my inexperience with both zephyr and micropython led me to believe that I just don´t know how to provide the proper tuple for the pin.
But after some research it seems there is a deprecation in the devicetree node property "label", which is the property used by device_get_binding() to get the device instance in mp_pin_make_new().

Updates in the .dts files (i.e. the dts/arm/nxp family used by the frdm_k64f board) seem to be removing this property, and the way of creating pins or machine instances as described in the docs won´t work for any board removing all labels (?).

Not sure if I am still missing something, and it is all simpler than this...
If that is not the case, are you aware of this issue? Any plan to update the port to the new dts specification? I am still getting my way into zephyr, but maybe using device_from_handle() instead?

Thanks a lot!

For extra context. These are the versions used here to build micropython:

• Zephyr version: 3.1.99
• Zephyr sdk: 0.13.2

[jaenrig-ifx]

Ok, some results over here:

After modifying the corresponding cpu dts files (adding a label) on zephyr I got the nrf52840dk board able to toggle a pin using the machine module and the Pin class.

I can state more confidently that for the current version (3.1.99) and newer of zephyr, 🔥 the mpy port will not work with any board which has removed the label property of the peripherals dts nodes 😿

[MaureenHelm]

I can state more confidently that for the current version (3.1.99) and newer of zephyr, fire the mpy port will not work with any board which has removed the label property of the peripherals dts nodes crying_cat_face

The mpy port will still work, but you need to change the device name string you use with zephyr class constructors.

Please see the documentation commit in #9335 :

zephyr: Update docs to reflect device name changes.

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.

[jaenrig-ifx]

@MaureenHelm, thanks for your support :)

That is great. I wasn´t aware that node names are also resolved by device_get_binding() 😓
I was hopeful that the instantiation naming could be a bit more user friendly from mpy side, and avoid all these device tree node names with unit-addresses. But I cannot think of a way without breaking the agnosticism for every board.
I can live with these naming 😃.

[MaureenHelm]

If you want to dig more into device name strings, please have a look at DEVICE_DT_DEFINE. Specifically, "The device structure's name field is set to DEVICE_DT_NAME(node_id)."

[jaenrig-ifx]

Mmm, I see:

Returns
The value of the node's "label" property, if it has one. Otherwise, the node's full name in "node-name@@unit-address" form.

As most of these macros are resolved during build time (since they are concatenating tokens), the only(?) usable C types that could be handled in runtime by device_get_binding() are the nodes names strings.

For end users to avoid using such tricky devicetree notation, maybe we could add some support python file/package with the list of available machine instances for a given board as you did in the docs examples in your pull request. Some like:

frdm_k64f_machine.py:

GPIO1_1 = ("gpio@400ff040", 1)
GPIO1_2= ...
...
I2C0= "i2c@xxx-xxx"

This file can be imported in the application any zephyr dts implementation specific abstracted at mpy level. For example:

from machine import Pin
import frdm_k64f_machine

led_pin = Pin((frdm_k64f_machine.GPIO1_1), Pin.OUT)

Or more generically, a zephyr_dts_machine_map.py package that is available as mpy module if the given mpy zephyr port board adds such file.
What do you think about this idea?

Not sure yet how/where to add this within the mpy zephyr port.

Thanks a lot for your support @MaureenHelm 😃

[Skyrov01]

Hi everyone! Thanks @jaenrig-ifx for raising this issue. I'm having the same problem with an RT1060. I'm new to zephyr and I'm trying to understand what changes I must do in order to override the dts. Hope you don't mind for asking this here, but didn't find any better place.

I'm currently using

• Zephyr version: 3.5.99
• Zephyr SDK: 0.16.3

And, as an extra detail, I'm getting a lot of deprecation warnings like the following one. Not sure if I should modify the micropython code to reflect the changes in Zephyr code.

In file included from /home/skyrov/work/micropython/ports/zephyr/mpconfigport.h:31,
                 from /home/skyrov/work/micropython/ports/zephyr/../../py/mpconfig.h:89,
                 from /home/skyrov/work/micropython/ports/zephyr/../../py/mpstate.h:31,
                 from /home/skyrov/work/micropython/ports/zephyr/../../py/runtime.h:29,
                 from /home/skyrov/work/micropython/ports/zephyr/mphalport.c:27:

#warning "<zephyr/zephyr.h> is deprecated, include <zephyr/kernel.h> instead" [-Wcpp]
   12 | #warning "<zephyr/zephyr.h> is deprecated, include <zephyr/kernel.h> instead"