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?

[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.

[Sigurd Hellesvik]

I have linked this ticket to our User Experience team; think it will be useful feedback to them.
I cannot promise that anything will change, but know that you have been heard.