Re:MicroPython v1.25.0
by antirez on Thursday May 15, 2025 @01:41AM
(#43992172)
Background for folks that are not into MicroPython. This release is so important because MicroPython is almost completely able to replace lower level languages like C for many embedded use cases on the RP20[45]0 and ESP32 and other MCUs at this point, being very solid, fast enough (and thanks to Viper and inline assembly abilities even super fast for critical code paths), portable across MPUs (super important: you can change MCU without rewriting everything), has very good support for SPI and other protocols, and so forth. But... the problem is, before this release MicroPython suffered not the CPU shortage, but RAM shortage: the bytecode needed to stay in memory, and once the program becomes big enough, memory is the bottleneck that limits the project size. To avoid that, you could build your own MicroPython binary with your frozen bytecode inside, in the device flash part, but... if I need to rebuild MicroPython part of the advantage of using it is gone (super fast development cycle is one of those). Well, now, with ROMFS, this is no longer true, MP itself is able to store bytecode in the device flash and execute from there. This makes MP a lot more practical for large embedded projects.
[ Parent
| on HN ]
Re:MicroPython v1.25.0
by anotherpaul on Thursday May 15, 2025 @02:17AM
(#43992310)
Thank you for explaining and giving context.
Re:MicroPython v1.25.0
by aero-glide2 on Thursday May 15, 2025 @01:55AM
(#43992225)
Is there still any point in learning Rust then
Re:MicroPython v1.25.0
by actionfromafar on Thursday May 15, 2025 @02:08AM
(#43992277)
You are downvoted, but for some things, no there isn't. MicroPython can be very useful for some use cases and it's safer than C.
Depends on the point of view regarding using languages with automatic resource management.
I learn all languages that I find interesting, even if I don't use them, because I am a systems programming nerd, in languages, graphics and operating systems.
So it is always interesting to have an understanding of what Rust is all about, even if I will never work professionaly with it.
Re:MicroPython v1.25.0
by whytevuhuni on Thursday May 15, 2025 @11:37AM
(#43996162)
Imagine trying to make some sort of MP3 player using an MCU. You’d be able to use MicroPython for the controls, but for decoding you won’t be able to get away with it, and you’ll need something like C/C++/Rust.
Like in the home computing days, you could use inline Assembly for the decoding loop.
We used DATA blocks, now they can use @micropython.asm_thum.
I see it as another take on BASIC for microcontrollers, like BASIC Stamp or mikroBasic, with a language that is more appealing to current generations.
We were able to already do so much on home computers back in the day, in an interactive development enviroment, no need to reach out for C in hardware that is x times better than those home computers.
> MicroPython's inline assembler now supports 32-bit RISC-V assembly code via the newly implemented @micropython.asm_rv32 decorator. This allows writing small snippets of RISC-V machine code that can be called directly from Python code. It is enabled on the rp2 port when the RP2350 is running in RISC-V mode.
Exciting!
I needed to whip up a small embedded hardware widget for a very large machinery project and with an Adafruit Feather + MicroPython I had the thing working in a day and respun the schematic into a working board by the end of the week. An RP2040 plus QSPI flash is a freaking dollar in the BOM, and that's priced in onesies from DigiKey.
I'm never going back my old standby (C on an NXP LPC4). This is the new normal and it's fantastic. I'm really excited to see ROMFS working on this part soon.
The best part of this is that, imagine tomorrow you want it running on ESP32 because out of the blue your board is now costly too much (this is just hypothetical: I'm for RP2040/50 for ALL uses but the most cheap requirements that need WiFi). Well, you can adapt it in 5 minutes.
I agree and that's going to be the biggest appeal: we can bury the HAL down into a library and you never have to deal with it again.
Adafruit did an incredible job putting all that abstraction across their products into a single "import board" statement.
Strong endorsement! I would like to add that MicroPython can also be extended in C by writing small (or large) modules in C that one can call from Python. There is a module variant that can be installed at runtime (via package manager) called dynamic native modules. This enables extending with native code without having to rebuild or reflash the firmware.