AtomVm support for Nordic nrf5x cpus

[brucebiotech]

Hi,

I am quite keen on having a go at adding support for Nordic cpus to atomvm. I currently work with the nrf52840, nrf5340, nrf9151 and am looking at the nrf5415. I use these chips for low power wireless mesh networking which erlang would be an awesome match for.

My approach would be to use Nordic's nrfx libray which is equivalent to the STM HAL used by the stm32 platform. I am guessing/hoping this means that a Nordic platform would follow the stm32 platform structure quite closely. In any case it will be achievable whereas trying to use zephyr is not IMHO.

Before I get going on this I am keen to know whether there is any other activity underway to add Nordic cpu support here and any thoughts on compatibility of the nrfx approach with the AtomVM code base?

Thanks

[bettio]

Hello,

Thanks for asking this. Support for Nordic CPUs is indeed something we would like to have. There is no activity at the moment on this topic, I've been evaluating Zephyr for this purpose, that avoids code duplication however I recognize there are some downsides as well.

I'll take a deeper look to nrfx as soon as I'm back from the ElixirConf. Meanwhile would you mind sharing more in detail your opinion on Zephyr? This kind of feedback is precious to us.

Regards,
Davide.

[brucebiotech]

I guess anyone using Nordic CPUs is confronted by zephyr in some way. My experience with it has led me to stick with nrfx and not use zephyr at all.

My headline view of zephyr vs erlang is that there is a complete functional overlap. And by overlap I mean that zephyr's functionality is a subset of AtomVM.

My alternative to zephyr is messaging passing/even-loop centric; i.e. focused on support for asynchronous communication, that I think would be a good match for the AtomVM. I have tried to use Nordic's zephyr as a resource to help with some of the hard bits, e.g. Cortex M33/ARMv8m security architecture support and USB device drivers. In each case I found zephyr an impenetrable black hole; i.e. no help at all. I would note that supporting the secure/non-secure cores in an ARMv8m CPU from AtomVM will be a bit of a challenge whatever path you choose. ARMv8m support is critical to maintain compatibility with the Nordic Bluetooth, NBIoT and NR+ libraries, so not optional for Nordic chips. For me, zephyr would make this very difficult.

The board support difference remains and zephyr does offer an easy "blinky" pathway on a lot of boards. However I favour a RIOT OS style approach to supporting CPU and board resources over zephyr's devicetree. An idea I am currently thinking about is why not parse zephyr's device tree source to generate some headers that implement board support for, in this case, AtomVM?

I could say much more but hopefully this gives you the flavour of my thoughts on zephyr.

Just for a bit of, possibly useful, additional background on me, I first encountered Erlang over 20 years ago. As part of a SCADA system development I had erlang/otp + linux running on an AVR32 microprocessor. I thought it was pretty cool but my employer didn't share the vision. So when I came across the AtomVM it reminded me of how good Erlang is and running it on micro controllers recaptured my interest.

Regards
Gregor