Zephyr port with working aioble on the Seeed Studio XIAO BLE NRF52840 SENSE board

[bikeNomad]

I've wanted to play with Zephyr and recently got some of these boards so why not make a MicroPython port?

https://github.com/bikeNomad/micropython-xiao_ble_nrf52840_sense

So far I have only tested the aioble temp_sensor.py demo program, but at least this should be a start.

I found the Zephyr port a bit incomplete and had to add a number of config entries to get everything to work.

Along the way I also patched the Zephyr port's UART handling to add mp_hal_stdio_poll() that was needed to get input() working right. (submitted a PR: #17606).

I also applied @dpgeorge 's PR #17599 to get the machine.Pin.value() working right.

Unfortunately, the zsensor.Sensor implementation isn't yet working with the on-board LSM6DS3TR-C IMU (issue #17597)

[bikeNomad]

I merged #17552, #17610, #17551, and #17599 onto 16f9d7f and tested with my XIAO BLE NRF52840 SENSE board; working well so far (though the zsensor.Sensor is not working, I can use raw I2C to talk to the IMU).

[jonnor]

Hi @bikeNomad, and thank you for putting together this! NRF52 is a super low-power BLE platform. The Zephyr port of MicroPython seems like a good way forward on these devices. As you note it is still rough, but that is precisely why we need testing, fixes etc. to push it forward. Is there any chance you could provide a pre-built binary?

I really like the XIAO BLE NRF52840 SENSE, due to the on-board sensors (and small size+batt charging). With the work you are doing here, I will consider it for future experiments in machine learning for these sensors (using https://github.com/emlearn/emlearn-micropython).

[bikeNomad]

Sure, here's a pre-built .uf2 file. I'd be interested to see your ML work!
https://github.com/bikeNomad/micropython-xiao_ble_nrf52840_sense/releases/tag/v0.1

[jonnor]

Thanks a lot! I will not have the chance to test right now, but hopefully in the coming weeks.

I saw that a bunch of the MRs have now been merged. Perhaps it could be time to get some board definitions into mainline MicroPython for a couple boards using the Zephyr port? I think this board could be a good candidate.

[jonnor]

As for ML, you might be interested in https://github.com/jonnor/toothbrush/ - just a simple and fun demo thingy. I seem to recall you mention IoT toothbrush in your MicroPython presentation :)

[bikeNomad]

Yes, one of the toothbrushes I've been working on is already on the market and the other is coming off the first production run right now. 🪥

[jonnor]

I got around to testing this a little bit now. First I noticed there seemed to be no fileystem. But I found your make_vfs.py script here, https://github.com/bikeNomad/micropython-xiao_ble_nrf52840_sense/blob/main/src/make_vfs.py
After running that, I see a filesystem. I was able to do mpremote mip install. However mpremote cp does not work?

These are OK

mpremote run make_vfs.py
mpremote mip install github:jonnor/micropython-npyfile

However the following all fail

[jon@jon-thinkpad toothbrush]$ mpremote cp make_vfs.py :/flash/
cp make_vfs.py :/flash/
mpremote: Error with transport:
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: 2

[jon@jon-thinkpad toothbrush]$ mpremote cp make_vfs.py :/
cp make_vfs.py :/
mpremote: Error with transport:
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: 2

[jon@jon-thinkpad toothbrush]$ mpremote cp make_vfs.py :/flash/
cp make_vfs.py :/flash/
mpremote: Error with transport:
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: 2

[jon@jon-thinkpad toothbrush]$ mpremote cp make_vfs.py :
cp make_vfs.py :
mpremote: Error with transport:
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: 2

[jon@jon-thinkpad toothbrush]$ mpremote ls :lib
ls :lib
       10040 mpu6886.py
        9255 npyfile.py
        8699 timebased.py

@bikeNomad any idea why this could happen? I tried removing all the files in lib/ as well, no change.

[jonnor]

I have made a custom build now. Was able to get accel_flasher.py to work. But this filesystem problem is still an issue - mpremote cp fails. But mpremote edit works. I have no idea what could be the cause.

[bikeNomad]

I don't know why the mpremote cp isn't working. I will try this with another Zephyr board.

[jonnor]

I found the problem. The build had #define MICROPY_PY_ERRNO (0) which causes the hashing of mpremote cp to trip. I made some notes around this at #17752 (comment)

When changing the configuration to #define MICROPY_PY_ERRNO (1), it works :) So maybe we should make sure the XIAO upstream build has that?

[jonnor]

I realized that I was on the wrong branch as well. I was on your oldest xiao branch. In the new one I did not have to fiddle with errno, it worked out-of-the-box :)

[jonnor]

Testing a bit more. I am able to set the on-board LEDs via pin = Pin(("gpio0", 6), Pin.OUT); pin.value(0). And I can create a PWM instance using pwm = PWM(("pwm0", 0), freq=100, duty_u16=10000). However, I have no idea which GPIO pin this PWM channel corresponds to? There is no mention of this in the Zephyr MicroPython docs... Browsing through Zephyr online resources, it appears that the PWM to GPIO mapping is usually done in the device tree? And from browsing the board code here, I cannot see any PWM being defined for any of the GPIO pins on available the board?
Is there no way to override this at runtime from MicroPython?

[jonnor]

I was able to add a PWM config and tested it with the on-board buzzer on the XIAO extension board.

Added the following to the overlay

/ {
    pwm_buzzers {
        compatible = "pwm-leds";
        buzzer1: buzzer1 {
            pwms = <&pwm0 0 PWM_MSEC(1) PWM_POLARITY_NORMAL>;
        };
    };
};

&pinctrl {
    pwm0_default: pwm0_default {
        group1 {
            // P0.29 has buzzer on XIAO extension board
            psels = <NRF_PSEL(PWM_OUT1, 0, 29)>;
        };
    };
};

[bikeNomad]

Ah... if you look at the generated zephyr.dts, you'll see that pwmleds is defined, and also pwm_led0, which is probably what you got for PWM(("pwm0", 0)).
It appears that only PWM0 is enabled.
And the implementation of the driver is somewhere in the NRFX codebase.

[jonnor]

Yeah it seems rather common for boards to have a PWM on some LED by default (which makes sense). I have not checked if the XIAO default PWM actually maps to one of the on-board LEDs.

[jonnor]

There appears to be a MR for this board into mainline now, #17679

[bikeNomad]

Yes, #17679 is mine.
Thanks for your testing and PWM contribution; I'll add this to my board definition.
As far as the PWM to GPIO pin mapping, I don't know how that would be done dynamically (I'm new to Zephyr).

[jonnor]

After more testing, I found that. Dynamic native C modules (natmod) currently crash/hang the board.
For external user C modules (extmod), the cmake for Zephyr port is missing some pieces. Have reported here, with a quickfix that worked for me. #17878