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.
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.
Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.
>>>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. ;-)
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.
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.
(And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))
If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.
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.