Micropython on nRF5340?

[ace.johnny]

I understand that Nordic has completely converted to Zephyr going forward, and will only support that OS for future development, but are there any technical limitations preventing community ports of Micropython for the nRF5340?

The nRF51 and nRF52 series already have ports of Micro/Circuitpython available, but I've found absolutely nothing regarding the nRF53. Obviously the SoC's complexity and full feature set can't be completely supported, but I'm surprised that there's not even a basic single-core build for this powerful platform at all.

Is it possible to reuse the nRF52 port on the nRF53, or are the architectural differences between them too pronounced? I'm not nearly proficient enough yet to attempt implementing a port myself, but I'm curious why seemingly no one else has tried. Is it simply not possible due to reasons beyond my novice comprehension?

[Sigurd Hellesvik]

Hi,

I understand that Nordic has completely converted to Zephyr going forward, and will only support that OS for future development, but are there any technical limitations preventing community ports of Micropython for the nRF5340?

I do not see any limitations myself. The nRF5340 is just two Cortex cores, and those will run code compiled by micropython.
Drivers for inter-core communication will be a bit complicated to use I think, but should be technically possible.

Other than that, remember to follow our Erratas when implementing it, those Errata fixes are one of the things that are easy to forget you get for free with our supported software.

Obviously the SoC's complexity and full feature set can't be completely supported, but I'm surprised that there's not even a basic single-core build for this powerful platform at all.

The Radio is only available to the network core, so to use both the application core (the powerful core) and the Radio, you need some type of intercore functionality.

Is it possible to reuse the nRF52 port on the nRF53, or are the architectural differences between them too pronounced? I'm not nearly proficient enough yet to attempt implementing a port myself, but I'm curious why seemingly no one else has tried. Is it simply not possible due to reasons beyond my novice comprehension?

I suspect you could reuse some but not all.
I will leave this answer up to the community.

Regards,
Sigurd Hellesvik

[ace.johnny]

It's disappointing that nothing simpler than Zephyr exists for the nRF53, since most other platforms offer at least several languages to choose from. When inspiration strikes on the nRF5340, it often quickly dissipates before slogging through the myriad intricacies involved, rather than easily banging out a functional (albeit less performant) proof of concept.

For the amount of effort, study, and time I've invested in NCS, you'd think I'd have more to show for it, but even as someone who's been programming since the Apple 2, I can accomplish so frustratingly little using Nordic's dictatorial choice of code. It has sadly sucked a lot of joy from my experience.

Having to port an entire language to such a staggeringly complex SoC just to simplify experimentation is unfortunately too big a task for me. I foolishly assumed that the nRF53 would be the next ubiquitously popular nRF52, but I've begun to regret my choice of DK selection.

Thank you though, Sigurd, for the patient and insightful response.

[Sigurd Hellesvik]

Your thoughts are definitively understandable, and thanks for wording them in such an orderly manner.

Here are some of my thoughts on the subject:

One of the large drawbacks of the nRF Connect SDK is the high learning curve. We are aware of this, and are working on improving this as best we can. https://academy.nordicsemi.com/ is one of my favorite efforts for this.

For the nRF52 series, we had one SDK, which we officially supported. I do not know how much resources we put into supporting other solutions, but I guess a lot of the support for the nRF52 series is not direct from us, but because it is so popular. A popular product has a higher chance of getting support in different places.

And speaking of popularity, while Zephyr can be hard to work with, it has become the largest RTOS. From wikipedia :
"As of January 2022, Zephyr had the largest number of contributors and commits compared to other RTOSes".
With so many people, I think and hope that it will become easier to use over time, both because a lot of people are working on improving it, and because a lot of guides will be made.

In a perfect work, we in Nordic would want to support other environments for our products as well.
However, we do not have unlimited resources and are forced to prioritize. We have chosen to focus on improving the nRF Connect SDK instead of splitting our focus into other stuff, such as Micropython.

None of the above are direct fixes for your complaints, but I hope that you get some value from them still

[ace.johnny]

Zephyr's popularity, and Nordic's stewardship thereof, are precisely why I decided to purchase a Nordic DK when diving head first down the rabbit hole of my personal RTOS studies. With a reputation for excellent documentation and support, along with several widely supported SoCs and strong brand recognition among embedded developers, I reasoned that the added expense would be worth it.

Maybe my first mistake was selecting the nRF5340 Audio DK, which rather than being a development kit for Zephyr audio as the name implies, is actually a board designed to support exactly one BLE example application. Attempting to reuse that DK for any other purpose is a nearly futile struggle, complicated by the fact that the example code doesn't even match the schematic or silkscreen.

It's rare that I'm unable to learn a subject that I'm both interested in and determined to master, but having spent two solid years now studying the nRF Connect SDK, I'm still barely even a beginner. Every single aspect has required yeoman effort; the West managed SDK, the bewildering Devicetree syntax and abstractions, the bottomless intertwined Kconfig options, not to mention the standard RTOS complications of multithreading, semaphores, and mutexes.

Having studied all of the above in detail, I understand the problems each of those tools solve, and the extraordinary capabilities they enable. I recognize the advantage of building NCS on top of Zephyr, and the unimaginably difficult task of integrating multiple independent open source projects into a cohesive whole, all of which are constantly moving targets. It is an endeavor I absolutely do not envy, and Nordic deserves accolades for their accomplishment.

But the result is that programming the nRF53 is never casual joyful play, it is exhausting focused toil. And while it is a remarkably powerful chip with an amazing feature set, it's one I no longer reach for due to the fatiguing mental labor involved. A Raspberry Pi Pico with a cheap DAC and nRF24 is exceedingly gobs more fun, substantially more approachable with multiple language support, and mere pennies of monetary outlay.

I really do appreciate your responses, Sigurd. I hope you'll likewise appreciate mine.