I'm implementing a few board specific functions that logically pertain to modmachine.c, for a board catered by the generic Zephyr port.

I'm curious what you mean by "logically pertain"?

The idea with the machine module is that it's well defined and documented, and so should not have anything custom added to it. Actually, that applies to pretty much all modules 😄

The recommended way for a board to add functionality is through additional modules that it defines (and documents). They can be modules implemented in C or Python (or both).

I'm curious what you mean by "logically pertain"?

Well, I'm implementing machine.lightsleep in a board-specific way. The function is supposed to be in the port modmachine.c, but Zephyr port is somewhat special - it's a collective port, that still allows for a specialized implementation.

I figured out a way to include my code in the most unintrusive way I could think of, that still allows me to use machine.lightsleep as expected from other ports.

Well, I'm implementing machine.lightsleep in a board-specific way

OK. In that case maybe a better solution is for your board definition to enable MICROPY_PY_MACHINE_BARE_METAL_FUNCS and then implement the required functions (mp_machine_unique_id etc) itself. That way it's not open for a board to add arbitrary things to machine but rather just implementing missing functionality.

Ideally machine.lightsleep() would be implemented consistently (and with the same code) for all zephyr boards. After all, the idea is that Zephyr itself provides a consistent API for all the different platforms. Have you seen #16864?

OK. In that case maybe a better solution is for your board definition to enable MICROPY_PY_MACHINE_BARE_METAL_FUNCS and then implement the required functions (mp_machine_unique_id etc) itself.

That's what I did, actually. I was just trying to implement precisely those functions for my specific board.

That way it's not open for a board to add arbitrary things to machine but rather just implementing missing functionality.

I see your point: my customization opens up machine too much. My intention is to add a board-specific implementation of the bare metal functions only, but the way I chose is not limited to that.

Ideally machine.lightsleep() would be implemented consistently (and with the same code) for all zephyr boards. After all, the idea is that Zephyr itself provides a consistent API for all the different platforms.

I get the point, but low power modes vary wildly from board to board. Zephyr PM support is very flexible, but also much more difficult to tame (to be expected, building a generic solution instead of a specific one is harder).

Have you seen #16864?

Well, I'm embassassed to admit that I missed it entirely 😊

That's what I tried to implement myself in my first attempt, only to find out that enabling CONFIG_PM and CONFIG_PM_DEVICE for Zephyr makes the console unusable on my board (quite likely it's not marked active at boot). This also happens with a Zephyr-only project unless I also add CONFIG_PM_DEVICE_RUNTIME, but that does not work correctly in MicroPython.

In any case, for my specific board it's not enough to power off the console - the system timers keep the CPU active, and machine.lightsleep just exits immediately. Also, disabling the interrupts does not bring the board to lowest power possibile - sleeping with unserviced interrupts seem to burn energy for nothing.

All in all, the "all boards implementation" provided won't work as expected on my board - and I'm pretty sure on others too.

also possibly relevant:

• Zephyr: GPIO / sensor interruptable lightsleep #18199

Thanks @dpgeorge , @Josverl for pointing me to a much better way to solve my problem. I've managed to produce a working Zephyr-only (thus hopefully generic) solution for lightsleep that actually goes into low power mode also for my board.

My code just adds a few lines to #18199 - I opened a PR on @bikeNomad 's repo with my changes (I'm unsure of how you manage this kind of stuff, it seemed sensible to maintain the original attribution).