4 ms·

Background for folks that are not into MicroPython. This release is so important because MicroPython is almost completely able to replace lower level languages

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.

aero-glide2 1y ago
Is there still any point in learning Rust then
- actionfromafar 1y ago
  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.
- pjmlp 1y ago
  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.
- whytevuhuni 1y ago
  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.
  - pjmlp 1y ago
    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.
anotherpaul 1y ago
Thank you for explaining and giving context.
pjmlp 1y ago
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.
sitkack 1y ago
> 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!
joezydeco 1y ago
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.
- antirez 1y ago
  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.
  - joezydeco 1y ago
    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.
jononor 1y ago
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.

aero-glide2 1y ago

Is there still any point in learning Rust then

actionfromafar 1y ago
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.
pjmlp 1y ago
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.
whytevuhuni 1y ago
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.
- pjmlp 1y ago
  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.

anotherpaul 1y ago

Thank you for explaining and giving context.

pjmlp 1y ago

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.

sitkack 1y ago

> 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!

joezydeco 1y ago

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.

antirez 1y ago
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.
- joezydeco 1y ago
  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.

jononor 1y ago

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.