4 ms·

I think this is good for someone getting started with microcontrollers(similar to the Arduino) However, one should not be disillusioned — I doubt this can be u

by ak_25 6y ago

I think this is good for someone getting started with microcontrollers(similar to the Arduino) However, one should not be disillusioned — I doubt this can be used to deploy a mass market product. However, I can see micro-python’s value in rapid-prototyping to some extent for someone who is not into embedded/firmware as much.

StavrosK 6y ago
Why not? I've used it and it works fine, you don't get the granular control you get with C but I don't think there's anything that makes it fundamentally unsuitable for production.
- ak_25 6y ago
  When you have a product that is running out of flash and you want to deploy an update for your customers, you need that granular control. I just can’t fathom deploying a full product where I don’t have this sort of control? From a performance/space standpoint there is decades of compiler optimization experience with IAR/GCC, I’m not sure micropython can achieve that.
  - StavrosK 6y ago
    I don't think it's inconceivable that there would be a product where you'd have ample storage and CPU power for your application and would want to optimize for speed of development instead. I've built things on MicroPython that would be just fine to ship as they were, for example, if I were to commercialize them.
    - ak_25 6y ago
      When engineers start cutting corners and start to design not for performance but “speed of development” — it becomes a slippery slope. I guess I’m speaking from the standpoint of a firmware engineer, I honestly don’t think going with micro-python for our next product will buy us anything. However, as I said; if you’re not into firmware and/or just getting started, this makes a great prototyping language.
      - StavrosK 6y ago
        If you're a firmware engineer and already familiar with the ins and outs of C, I don't think it buys you anything, agreed. I also don't think there's something fundamentally wrong with it that would force a hobbyist to rewrite everything in C if they wanted to commercialize their prototype.
        ak_25 6y ago
        I can agree with this. If you find a language that is more approachable and gets stuff done, you should go for it. (And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))
      - pjmlp 6y ago
        For me, some of the hardware supported by MicroPython is more powerful that what I had on a desk during my MS-DOS days, so I can easily see using it for certain kinds of applications. If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.
      - schwartzworld 6y ago
        you're being a little hyperbolic. haven't you ever heard of premature optimization?
- embedpythony 6y ago
  There are a few reasons. Number one, stability issues from heap fragmentation. http://docs.micropython.org/en/latest/reference/constrained.html#ram http://docs.micropython.org/en/latest/reference/constrained.... Even if you are careful about manual allocation, Python is not a compiled language, and the interpreter will frequently request heap allocations on its own. So if you expect a program to run for a long time without crashing, you'll probably need to use much less memory than the system has available. It's also quite slow. That's not a huge issue since modern microcontrollers are fast and you can write your own .mpy modules in C, but it does affect power consumption. It's also pretty high on the "drama" scale as far as OSS projects go. Last I checked, there was a brewing split between the original maintainer and one of the largest contributors, and Adafruit have already gotten frustrated enough to make a hard fork called CircuitPython. Personally, I would use it a lot more if I could trust it to run stably. For reference, I've used it in a Cortex-M0 clock which can run more or less indefinitely, but needs 16-32KB of RAM just to read an I2C clock and set some 7-segments. And when I tried to set up a simple wireless MQTT sensor with a supported Cortex-M4 board, I couldn't get it to run longer than a few days before the application crashed from memory fragmentation. So from my perspective, it is only usable for trivial tasks, and even if it were more stable, I'm not sure which fork would be the right choice for long-term development. Still, it's an excellent educational tool and I always like to see more of those.
  - jennasys 6y ago
    Adafruit's fork was for business reasons as they wanted control over implementation for the hardware they sell, and to focus development efforts on making it more accessible to newcomers. While I'm not thrilled with the fork since it dilutes the original project imo, they do still contribute back to the micropython project. But I don't think there's any lost love there, they just had different goals with a financial stake (unlike the uasyncio split which was ego driven)
  - mianos 6y ago
    I have an ESP8266 running MQTT to make an alert on a speaker (I2C) on demand. I just looked at the counter I periodically send to MQTT. It has been up for over 200 days. It does not leak.
pmorici 6y ago
Digi started using it as the user facing API for the programmable version of there xbee radio modules and those are very popular.
analog31 6y ago
In my view, nothing can be used to deploy a product, without further consideration. My rationale for saying this is that in addition to programming in any language, you need to understand hardware, including safety. And I think that by the time a person reaches that level of knowledge, they have probably familiarized themselves with programming at a variety of levels from bare-metal C up to desktop software. Now, I've only been playing with MicroPython (actually the CircuitPython fork) for a few months, and at this point haven't come up with a "scale" of project that needs more than bare metal C but less than a full blown operating system. But then again I haven't come up with any good product ideas in that time period. As I mentioned to a friend of mine: "Hi, we're programmers, and we're here to burn your house down." Between the two real projects that I'm nursing along right now, one uses a FFT and the other an interrupt running at 170 kHz, so neither of those can be pure Python projects yet.
- matt_trentini 6y ago
  > one uses a FFT and the other an interrupt running at 170 kHz Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.
  - analog31 6y ago
    Yes, definitely. Any application that I can think of off the top of my head involves adding C code. This is not a hurdle, but would be for someone who is using Python to get into embedded programming at a beginner level. From the MicroPython documentation: >>>Compiling the cmodule into MicroPython >>>To build such a module, compile MicroPython (see getting started) with an extra make flag named USER_C_MODULES set to the directory containing all modules you want included (not to the module itself). For example: ... This is not precisely for the faint of heart, but should not be prohibitive for a seasoned embedded developer. ;-)
- ac29 6y ago
  You might be interested in ulab for FFT and other numpy-ish things: https://micropython-ulab.readthedocs.io/en/latest/ulab.html#fft-routines https://micropython-ulab.readthedocs.io/en/latest/ulab.html#...
matt_trentini 6y ago
Everyone is open to their opinion; in the meantime the company I work for uses it for mass market devices in the medical domain. ;)

by ak_25 6y ago

StavrosK 6y ago

Why not? I've used it and it works fine, you don't get the granular control you get with C but I don't think there's anything that makes it fundamentally unsuitable for production.

ak_25 6y ago
When you have a product that is running out of flash and you want to deploy an update for your customers, you need that granular control. I just can’t fathom deploying a full product where I don’t have this sort of control? From a performance/space standpoint there is decades of compiler optimization experience with IAR/GCC, I’m not sure micropython can achieve that.
- StavrosK 6y ago
  I don't think it's inconceivable that there would be a product where you'd have ample storage and CPU power for your application and would want to optimize for speed of development instead. I've built things on MicroPython that would be just fine to ship as they were, for example, if I were to commercialize them.
  - ak_25 6y ago
    When engineers start cutting corners and start to design not for performance but “speed of development” — it becomes a slippery slope. I guess I’m speaking from the standpoint of a firmware engineer, I honestly don’t think going with micro-python for our next product will buy us anything. However, as I said; if you’re not into firmware and/or just getting started, this makes a great prototyping language.
    - StavrosK 6y ago
      If you're a firmware engineer and already familiar with the ins and outs of C, I don't think it buys you anything, agreed. I also don't think there's something fundamentally wrong with it that would force a hobbyist to rewrite everything in C if they wanted to commercialize their prototype.
      - ak_25 6y ago
        I can agree with this. If you find a language that is more approachable and gets stuff done, you should go for it. (And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))
    - pjmlp 6y ago
      For me, some of the hardware supported by MicroPython is more powerful that what I had on a desk during my MS-DOS days, so I can easily see using it for certain kinds of applications. If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.
    - schwartzworld 6y ago
      you're being a little hyperbolic. haven't you ever heard of premature optimization?
embedpythony 6y ago
There are a few reasons. Number one, stability issues from heap fragmentation. http://docs.micropython.org/en/latest/reference/constrained.html#ram http://docs.micropython.org/en/latest/reference/constrained.... Even if you are careful about manual allocation, Python is not a compiled language, and the interpreter will frequently request heap allocations on its own. So if you expect a program to run for a long time without crashing, you'll probably need to use much less memory than the system has available. It's also quite slow. That's not a huge issue since modern microcontrollers are fast and you can write your own .mpy modules in C, but it does affect power consumption. It's also pretty high on the "drama" scale as far as OSS projects go. Last I checked, there was a brewing split between the original maintainer and one of the largest contributors, and Adafruit have already gotten frustrated enough to make a hard fork called CircuitPython. Personally, I would use it a lot more if I could trust it to run stably. For reference, I've used it in a Cortex-M0 clock which can run more or less indefinitely, but needs 16-32KB of RAM just to read an I2C clock and set some 7-segments. And when I tried to set up a simple wireless MQTT sensor with a supported Cortex-M4 board, I couldn't get it to run longer than a few days before the application crashed from memory fragmentation. So from my perspective, it is only usable for trivial tasks, and even if it were more stable, I'm not sure which fork would be the right choice for long-term development. Still, it's an excellent educational tool and I always like to see more of those.
- jennasys 6y ago
  Adafruit's fork was for business reasons as they wanted control over implementation for the hardware they sell, and to focus development efforts on making it more accessible to newcomers. While I'm not thrilled with the fork since it dilutes the original project imo, they do still contribute back to the micropython project. But I don't think there's any lost love there, they just had different goals with a financial stake (unlike the uasyncio split which was ego driven)
- mianos 6y ago
  I have an ESP8266 running MQTT to make an alert on a speaker (I2C) on demand. I just looked at the counter I periodically send to MQTT. It has been up for over 200 days. It does not leak.

pmorici 6y ago

Digi started using it as the user facing API for the programmable version of there xbee radio modules and those are very popular.

analog31 6y ago

In my view, nothing can be used to deploy a product, without further consideration. My rationale for saying this is that in addition to programming in any language, you need to understand hardware, including safety. And I think that by the time a person reaches that level of knowledge, they have probably familiarized themselves with programming at a variety of levels from bare-metal C up to desktop software. Now, I've only been playing with MicroPython (actually the CircuitPython fork) for a few months, and at this point haven't come up with a "scale" of project that needs more than bare metal C but less than a full blown operating system. But then again I haven't come up with any good product ideas in that time period. As I mentioned to a friend of mine: "Hi, we're programmers, and we're here to burn your house down." Between the two real projects that I'm nursing along right now, one uses a FFT and the other an interrupt running at 170 kHz, so neither of those can be pure Python projects yet.

matt_trentini 6y ago
> one uses a FFT and the other an interrupt running at 170 kHz Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.
- analog31 6y ago
  Yes, definitely. Any application that I can think of off the top of my head involves adding C code. This is not a hurdle, but would be for someone who is using Python to get into embedded programming at a beginner level. From the MicroPython documentation: >>>Compiling the cmodule into MicroPython >>>To build such a module, compile MicroPython (see getting started) with an extra make flag named USER_C_MODULES set to the directory containing all modules you want included (not to the module itself). For example: ... This is not precisely for the faint of heart, but should not be prohibitive for a seasoned embedded developer. ;-)
ac29 6y ago
You might be interested in ulab for FFT and other numpy-ish things: https://micropython-ulab.readthedocs.io/en/latest/ulab.html#fft-routines https://micropython-ulab.readthedocs.io/en/latest/ulab.html#...

matt_trentini 6y ago

Everyone is open to their opinion; in the meantime the company I work for uses it for mass market devices in the medical domain. ;)