33 ms·

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For insta

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For instance it’s a lot easier and faster and less verbose to quickly get some http server communication going on the ESP32 in Micropython rather than the C equivalent. The downsides are somewhat dramatic though - it’s, of course, a lot slower and hungrier for memory than the C equivalent code, but it’s also still missing a lot of API’s and fine grained control, at least for the ESP32. For instance, what finally made me switch to the ESP-IDF was complete lack of support for ADC2 on ESP32 in Micropython. Having to recompile the Micropython firmware to change a good chunk of the configuration parameters was also annoying because it takes a decent amount of time to compile and reflash firmware. Bottom line is that Micropython is a great project for certain things - some home automation and simple sensors. On things where performance doesn’t matter or isn’t bottlenecked by the Python interpreter (like simple HTTP communication) it’s great. It also has a surprisingly robust open source driver ecosystem, provided you aren’t trying to do anything fancy with SPI. It falls apart when you need to work with it professionally though. So use it to build and test your product, but rewrite it in C/C++ when it gets closer to ship time.

samwillis 4y ago
I had a similar experience, however the “native” and “viper” code emitters do a very good job of allowing you to optimise performance bottlenecks. It’s a lot like Cython. https://docs.micropython.org/en/kookaberry/reference/speed_python.html?highlight=native#the-native-code-emitter https://docs.micropython.org/en/kookaberry/reference/speed_p... https://docs.micropython.org/en/kookaberry/reference/speed_python.html?highlight=native#the-viper-code-emitter https://docs.micropython.org/en/kookaberry/reference/speed_p...
codetiger 4y ago
Yes, I have been using MicroPython on ESP32 and RPi Pico. For projects like home automation, it was super easy and handy. When I started building a game console using RPi Pico (https://github.com/codetiger/GameTiger-Console https://github.com/codetiger/GameTiger-Console), I had to rewrite as Python interpreter takes a lot of memory and leaves very little for the application. In my case, I had to avoid using Framebuffer on MicroPython. After switching to C++, its all in your control and take lot of time to write the same simple things
- pjmlp 4y ago
  I think what used to be BASIC / Assembly relationship back when hardware comparable to ESP32 used to take a whole desk, is now Python / C++ instead.
a2800276 4y ago
One thing to add from my experiences: it's dramatically more accessible to beginners than Arduino and way more useful for building one-offs/prototypes as well.
- iostream24 4y ago
  My personal experience was the opposite. I own two identically equipped boards: the Seeed Studio ArchMix and the Teensy 4.1 On the archmix, I managed to boot up and that’s about it. There was literally a REPL and I was able to blink the LED and then I couldn’t proceed further, where was I supposed to code? Bad experience. Teensy: connect the board , fire up the teensyduino ide, choose an interesting example from the drop down menu, run it, rinse and repeat until you are familiar with idioms for all sorts of things, real hardware examples they do real things, real peripheral support in the form of examples
  - a2800276 4y ago
    I agree that the user experience, onboarding etc. are very well executed for Arduino (and especially for the ESP32 port of uPython could use some polishing)... > rinse and repeat until you are familiar with idioms for all sorts of things Except that the idioms you learn are really not suitable for anything but toy examples. Arduino is rotten from the core: "setup", "loop" and "delay" are the worst imaginable way to write embedded software, yet everyone coming from Arduino thinks this is how well written embedded software should look.
    - noedig2 4y ago
      > "setup", "loop" and "delay" are the worst imaginable way to write embedded software I agree with "delay", but why do you say setup and loop are the worst imaginable way to write embedded software?
      - jdcarter 4y ago
        > why do you say setup and loop are the worst imaginable way to write embedded software? Because there's neither abstraction nor ways to combine things. Say you have a device that needs to do two things, and you look up some examples of how to do each thing. Each example is going to have its own loop() function--but how do you combine them? There's no notion of tasks or threads. There's no abstraction for device drivers. Arduino is a system that paints you straight into a corner. [edit to add] Any reasonable software environment needs to provide three things, quoting "Structure and Interpretation of Computer Programs" here [1]: * primitive expressions, which represent the simplest entities the language is concerned with, * means of combination, by which compound elements are built from simpler ones, and * means of abstraction, by which compound elements can be named and manipulated as units. Arduino only provides the first. [1]: https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1 https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
stinos 4y ago
> It falls apart when you need to work with it professionally though More accurately: it falls apart when you need it professionally :) Totally depends on the usecase.
- nuclearnice1 4y ago
  What did you end up using MicroPython for?
  - matt_trentini 4y ago
    My company uses it for medical device development, ama if it will help!
    - nuclearnice1 4y ago
      Very cool. Are you prototyping or manufacturing at scale? What kind of sensors have you attached?
      - matt_trentini 4y ago
        Manufacturing at scale. Though these are medical - not consumer - devices so we're not talking hundreds of thousands of units. Think high-quality, injection molded, moderately sophisticated devices. Typically hundreds and up to several thousands of units, depending on the project. We use all manner of sensors; temperature, pressure, cap touch, photodiode detection, cameras.
  - stinos 4y ago
    Frontend for writing behavioral experiments. So backend runs C++ signal processing etc, graphics display, or whatever we need, all of that has bindings for MicroPython. Works very well, but: it's still Python. Great, but dynamic so not the best suited for larger applications in my experience - no matter how well-architected the code is. Becomes just really hard to refactor without breaking anything.
- SOLAR_FIELDS 4y ago
matt_trentini 4y ago
The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us. Indeed, it's helped deliver high-quality solutions quickly...
- turbinerneiter 4y ago
  You have to have the right people. They have to like Python and want to use it, but not because they think "C is too hard". They have to be happy writing Python code and confident enough to write modules in C and work on MicroPython itself. There is some steps necessary to go from "prototyping MicroPython" to "production MicroPython" and many people either forget about them, are not skilled enough to do them (which is fine, MicroPython is about onboarding people to embedded as well) or they feel like these steps make using MicroPython pointless.
  - matt_trentini 4y ago
    > You have to have the right people. Yes, true! I presented a lightning talk to colleagues on "Ingredients for Commercial MicroPython Success". One of the key points is "People are critical". Maybe folks here might find it useful: https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvEqUeuzj1rIY5XyZrW8P_sSggKmZ9vs-TVZNFy_9vdB9rYrVMIcmcg98dfBUoNPIMEKHM/pub https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvE...
- IshKebab 4y ago
  That's worrying. I can't think of a less appropriate application for something as fragile as Python.
  - matt_trentini 4y ago
    The MicroPython interpreter is very robust and well tested. We test our devices extensively. You need to pay attention to gc performance, memory use and fragmentation but this isn't our first rodeo! Systems are typically fragile because of poor system design not language choice. I've worked on many C and C++ systems and there's nothing inherently more robust about them. Some would argue that the various ways you can trip over UB makes them more fragile...
R0b0t1 4y ago
Did you try running it on top of Zephyr?
- matt_trentini 4y ago
  I don't personally use the Zephyr port, though it has plenty of potential. But it's worth sharing that the Renode folks have put together a MicroPython on Zephyr dashboard to show that at least 90 of their simulated boards appear to reach the REPL: https://zephyr-dashboard.renode.io/dashboard-micropython.html https://zephyr-dashboard.renode.io/dashboard-micropython.htm... Any of those that are passing would be a good board to choose to start with.

samwillis 4y ago

I had a similar experience, however the “native” and “viper” code emitters do a very good job of allowing you to optimise performance bottlenecks. It’s a lot like Cython. https://docs.micropython.org/en/kookaberry/reference/speed_python.html?highlight=native#the-native-code-emitter https://docs.micropython.org/en/kookaberry/reference/speed_p... https://docs.micropython.org/en/kookaberry/reference/speed_python.html?highlight=native#the-viper-code-emitter https://docs.micropython.org/en/kookaberry/reference/speed_p...

codetiger 4y ago

Yes, I have been using MicroPython on ESP32 and RPi Pico. For projects like home automation, it was super easy and handy. When I started building a game console using RPi Pico (https://github.com/codetiger/GameTiger-Console https://github.com/codetiger/GameTiger-Console), I had to rewrite as Python interpreter takes a lot of memory and leaves very little for the application. In my case, I had to avoid using Framebuffer on MicroPython. After switching to C++, its all in your control and take lot of time to write the same simple things

pjmlp 4y ago
I think what used to be BASIC / Assembly relationship back when hardware comparable to ESP32 used to take a whole desk, is now Python / C++ instead.

a2800276 4y ago

One thing to add from my experiences: it's dramatically more accessible to beginners than Arduino and way more useful for building one-offs/prototypes as well.

iostream24 4y ago
My personal experience was the opposite. I own two identically equipped boards: the Seeed Studio ArchMix and the Teensy 4.1 On the archmix, I managed to boot up and that’s about it. There was literally a REPL and I was able to blink the LED and then I couldn’t proceed further, where was I supposed to code? Bad experience. Teensy: connect the board , fire up the teensyduino ide, choose an interesting example from the drop down menu, run it, rinse and repeat until you are familiar with idioms for all sorts of things, real hardware examples they do real things, real peripheral support in the form of examples
- a2800276 4y ago
  I agree that the user experience, onboarding etc. are very well executed for Arduino (and especially for the ESP32 port of uPython could use some polishing)... > rinse and repeat until you are familiar with idioms for all sorts of things Except that the idioms you learn are really not suitable for anything but toy examples. Arduino is rotten from the core: "setup", "loop" and "delay" are the worst imaginable way to write embedded software, yet everyone coming from Arduino thinks this is how well written embedded software should look.
  - noedig2 4y ago
    > "setup", "loop" and "delay" are the worst imaginable way to write embedded software I agree with "delay", but why do you say setup and loop are the worst imaginable way to write embedded software?
    - jdcarter 4y ago
      > why do you say setup and loop are the worst imaginable way to write embedded software? Because there's neither abstraction nor ways to combine things. Say you have a device that needs to do two things, and you look up some examples of how to do each thing. Each example is going to have its own loop() function--but how do you combine them? There's no notion of tasks or threads. There's no abstraction for device drivers. Arduino is a system that paints you straight into a corner. [edit to add] Any reasonable software environment needs to provide three things, quoting "Structure and Interpretation of Computer Programs" here [1]: * primitive expressions, which represent the simplest entities the language is concerned with, * means of combination, by which compound elements are built from simpler ones, and * means of abstraction, by which compound elements can be named and manipulated as units. Arduino only provides the first. [1]: https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1 https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

stinos 4y ago

> It falls apart when you need to work with it professionally though More accurately: it falls apart when you need it professionally :) Totally depends on the usecase.

nuclearnice1 4y ago
What did you end up using MicroPython for?
- matt_trentini 4y ago
  My company uses it for medical device development, ama if it will help!
  - nuclearnice1 4y ago
    Very cool. Are you prototyping or manufacturing at scale? What kind of sensors have you attached?
    - matt_trentini 4y ago
      Manufacturing at scale. Though these are medical - not consumer - devices so we're not talking hundreds of thousands of units. Think high-quality, injection molded, moderately sophisticated devices. Typically hundreds and up to several thousands of units, depending on the project. We use all manner of sensors; temperature, pressure, cap touch, photodiode detection, cameras.
- stinos 4y ago
  Frontend for writing behavioral experiments. So backend runs C++ signal processing etc, graphics display, or whatever we need, all of that has bindings for MicroPython. Works very well, but: it's still Python. Great, but dynamic so not the best suited for larger applications in my experience - no matter how well-architected the code is. Becomes just really hard to refactor without breaking anything.
SOLAR_FIELDS 4y ago

matt_trentini 4y ago

The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us. Indeed, it's helped deliver high-quality solutions quickly...

turbinerneiter 4y ago
You have to have the right people. They have to like Python and want to use it, but not because they think "C is too hard". They have to be happy writing Python code and confident enough to write modules in C and work on MicroPython itself. There is some steps necessary to go from "prototyping MicroPython" to "production MicroPython" and many people either forget about them, are not skilled enough to do them (which is fine, MicroPython is about onboarding people to embedded as well) or they feel like these steps make using MicroPython pointless.
- matt_trentini 4y ago
  > You have to have the right people. Yes, true! I presented a lightning talk to colleagues on "Ingredients for Commercial MicroPython Success". One of the key points is "People are critical". Maybe folks here might find it useful: https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvEqUeuzj1rIY5XyZrW8P_sSggKmZ9vs-TVZNFy_9vdB9rYrVMIcmcg98dfBUoNPIMEKHM/pub https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvE...
IshKebab 4y ago
That's worrying. I can't think of a less appropriate application for something as fragile as Python.
- matt_trentini 4y ago
  The MicroPython interpreter is very robust and well tested. We test our devices extensively. You need to pay attention to gc performance, memory use and fragmentation but this isn't our first rodeo! Systems are typically fragile because of poor system design not language choice. I've worked on many C and C++ systems and there's nothing inherently more robust about them. Some would argue that the various ways you can trip over UB makes them more fragile...

R0b0t1 4y ago

Did you try running it on top of Zephyr?

matt_trentini 4y ago
I don't personally use the Zephyr port, though it has plenty of potential. But it's worth sharing that the Renode folks have put together a MicroPython on Zephyr dashboard to show that at least 90 of their simulated boards appear to reach the REPL: https://zephyr-dashboard.renode.io/dashboard-micropython.html https://zephyr-dashboard.renode.io/dashboard-micropython.htm... Any of those that are passing would be a good board to choose to start with.