MicroPython v1.25.0(github.com)
github.com
MicroPython v1.25.0
https://github.com/micropython/micropython/releases/tag/v1.25.0
29 comments
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.
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.
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.
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.
Adafruit did an incredible job putting all that abstraction across their products into a single "import board" statement.
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.
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!
Exciting!
Is there still any point in learning Rust then
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.
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.
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.
We used DATA blocks, now they can use @micropython.asm_thum.
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.
Thank you for explaining and giving context.
I find it interesting that MicroPython's `re` module[0] is implemented with a backtracking regular expression engine from re1.5[1], instead of one of the linear-time engines from the same library. (Russ Cox covers the various engines in the excellent blog series[2] which re1 is a companion to.) I figure the choice was made due to binary size or memory constraints, though they're all quite small.
[0]: https://github.com/micropython/micropython/tree/master/lib/r...
[1]: https://github.com/pfalcon/re1.5/tree/v0.8.2
[2]: https://swtch.com/~rsc/regexp/regexp2.html
[0]: https://github.com/micropython/micropython/tree/master/lib/r...
[1]: https://github.com/pfalcon/re1.5/tree/v0.8.2
[2]: https://swtch.com/~rsc/regexp/regexp2.html
Yes, it was chosen for low size and memory constraints. But it is limited in features (like counted repetitions):
https://docs.micropython.org/en/latest/library/re.html
so alternatives to provide additional features have been discussed... Either extending the existing module or swapping to a more feature-rich library. Possibly even doing so for larger micros that can afford the additional flash/memory, though that makes support more challenging.
https://docs.micropython.org/en/latest/library/re.html
so alternatives to provide additional features have been discussed... Either extending the existing module or swapping to a more feature-rich library. Possibly even doing so for larger micros that can afford the additional flash/memory, though that makes support more challenging.
I was talking about the performance, not the feature set. Russ Cox's re1 and the re1.5 fork have several engines for different implementation strategies. re1 was written for primarily pedagogical reasons, so its minimality comes from that.
The engine chosen by MicroPython is vulnerable to catastrophic backtracking and switching to the Pike VM implementation would fix that. Instead of backtracking in the text when the pattern doesn't match, the Pike VM iterates each char in the text only once, visiting the states valid for that position in lock step. Consequently, it allocates a list of “thread”s, proportional in length to the number of states in the pattern (though usually patterns have relatively few states). Many security issues have resulted from regexp denials of service, so this slight memory tradeoff might be worthwhile.
Since recursiveloop.c has been changed by MicroPython, those changes would need to be ported to pike.c. The fixes are small and none of the extra features exploit the backtracking, so this should be easy.
The engine chosen by MicroPython is vulnerable to catastrophic backtracking and switching to the Pike VM implementation would fix that. Instead of backtracking in the text when the pattern doesn't match, the Pike VM iterates each char in the text only once, visiting the states valid for that position in lock step. Consequently, it allocates a list of “thread”s, proportional in length to the number of states in the pattern (though usually patterns have relatively few states). Many security issues have resulted from regexp denials of service, so this slight memory tradeoff might be worthwhile.
Since recursiveloop.c has been changed by MicroPython, those changes would need to be ported to pike.c. The fixes are small and none of the extra features exploit the backtracking, so this should be easy.
I'm a bit confused about the Pyboard. Do people buy Pyboards instead of ESP32 in order to support the project, or because they are more featureful, or both? Why does the Pyboard have a CPU in addition to the microcontroller, does the microcontroller only deal with IO?
Quick search shows the v1.1 at least it's just a microcontroller and a uSD slot. So I'd imagine it's just about support. With all the ESP32 boards out there, sky's the limit on word behavior you could get from flaky hardware.
Ah yes, I read "STM" and immediately figured it was one of those old school very low MHz microcontrollers but apparently those are available with ARM cores too... possibly had 'em confused with AVR/ATmega.
As a habitual STM user professionally,... Yes. Not the highest performance but high enough and good peripherals. The blue pill is a STM.
offtopic I am curious anyone tried using micropython to replace CPython o x86 servers?
Yes, although MicroPython is focused on running on microcontrollers it can be useful if you want to reduce memory consumption, flash space and even startup time on servers.
The challenge is that MicroPython has many fewer standard libraries:
https://github.com/micropython/micropython/wiki/Standard-Lib...
And so many Python libraries targeting CPython won't work out-of-the box and you'll need to modify them or use alternatives that do work on the MicroPython subset.
The challenge is that MicroPython has many fewer standard libraries:
https://github.com/micropython/micropython/wiki/Standard-Lib...
And so many Python libraries targeting CPython won't work out-of-the box and you'll need to modify them or use alternatives that do work on the MicroPython subset.
I've not used MicroPython, but its fork, CircuitPython. My impression is that it's essentially a Python that doesn't interact with an operating system. Thus if there's a reason for a server to have an OS and interact with it, the regular Python would be preferable.
I also don't know how much of the more advanced optimizations of Python are built into MicroPython. There's always a dilemma between making it performant, and making it micro.
I also don't know how much of the more advanced optimizations of Python are built into MicroPython. There's always a dilemma between making it performant, and making it micro.
Only really feasible if your program does not have any CPython C module dependencies. As there is no API compatibility with those.
Seems pretty cool. As someone who never did anything on such low specced hardware (so not knowing if it's truly comparable), I also found http://www.ulisp.com/ quite interesting to look at.
I want to integrate MP to my project. The core FW is still in c/cpp, but the UI/UX and some logic could be done in Python. But i feel like MP want to be the center of FW.
MicroPython can be used either as the top-level entry point, with your C/C++ code being modules (callable from Python). Or you can embed the interpreter into a C/C++ program - see the "embed" port for an example.
Lots of cool improvements.