What is basic hardware requirements for micropython

[eckorsberg]

The baseline processor for micropython is a 32 bit ARM STM32F405RG.
In general is the software design of micropython dependent upon a 32 bit architecture or could it scale down to much smaller micro controllers like the TI MSPG2553IN20 (among many similar flavors of this)?

[torwag]

As far as I understood, the most current limitation is the memory size (beside of practical usability).
Thus, I guess smaller uCs simply do not have enough memory to start micropython.

[eckorsberg]

Do we understand what are the practical minimum memory requirements to run Micropython?

As far as I understood, the most current limitation is the memory size (beside of practical usability).
Thus, I guess smaller uCs simply do not have enough memory to start micropython.

[schuschu]

Just out of curiosity: Is it currently possible/intended to run the code on any other stm32 board (discovery with a f401, nucleo with a f407) or are the requirements strictly a f405?

[JonHylands]

We've run it successfully on the processor on the Teensy 3.1, which is a Freescale Cortex M4 with 64 KB of RAM, and 256 KB of FLASH, running at 96 MHz. With a fairly small (7 classes) application running, I was consuming about 56 KB of RAM.

- Jon

[torwag]

It also runs already on the Discovery board.
It is indeed intended to port micropython to many other boards. Damien tries to provide a porting guideline as soon as time permits.
From there it should be an interesting task to port it to the uC of choice.
As I understood, the uC would require a minimum of RAM and ROM as well as speed to be really usable. 32bit might be a neccearity.
Micropython is much more rather then running python on an OS. Beside of porting a lot of code towards the target system, one has to deal with the unique features and shortcomings of a certain controller.
I think this limits micropython at the moment to ARM-based uC, but other families might be added later.

On the kickstarter web-page Damien wrote a bit about certain minimum requirements:

RAM: > 64kB (64kB might be a minimum, but does not leave much space for the real application)
Flash: > 256kB (might work with less, see below)
Clock: >70MHz

These are not fixed values. However, one need to estimate what would be the practical output of system with even lower specs, beside of being a proof of concept. No real benefit, if there is no space for the real application (RAM and ROM) or if it take to much time to perform a certain task (clock). Sure the all this could be tweaked by a lot of code improvement, code emitters, inline-assembler, etc. However, it would diminish the usage of a language like python on a microcontroller, if you have to perform all those tweaks to already to very basic tasks.
Secondly, mircopython might grow over time and the minimum requirements might increase, thus it is not a bad idea to leave some space for future updates. Being stuck to an older version of micropython because the controller runs out of RAM or ROM is kind of disappointing.

The nucleo (which should be an f401) should still be ok and a port should be relatively easy (similar like the discovery boards).

[pfalcon]

Do we understand what are the practical minimum memory requirements to run Micropython?

I would (eventually) target 4Kb as the minimum RAM size (which amounts to ~2Kb heap) and 64Kb as the minimum ROM size. This would be highly limited build (for example, only bytecode VM, no source parser), and such highly limited heap won't allow to do much beyond LED blinking. More realistic figures are 8Kb RAM/128K ROM. With that, it still remains rather limited, but with special consideration and optimization, it should be possible to write apps which do things beyond trivial. As usual with high-level languages, heap size is a limiting factor. To run apps written in the same way as for "desktops", you'd need a lot of it. 256Kb of "ROM" should be enough for majority of MicroPython usecases.

[fma]

Is it possible to monitor RAM/ROM usage when trying code under unix-target build? Would it match RAM/ROM usage on stm-target build?

[torwag]

Hi pfalcon,

target 4Kb as the minimum RAM size (which amounts to ~2Kb heap) and 64Kb ROM

are you sure about that figures? It would be much less compared to statements Damien gave on the kickstarter page.

Anyhow, I think a good practical orientation would be to look at the pyboard. Sure one might get away by less RAM / ROM / Clock speed. However, I simply guess Damien did select the particular controller not without reason

BTW. Did you mean kB or kb... guess you mean kilobyte (kB) ?! As for kilobit (kb) this would really be tide

[pfalcon]

Secondly, mircopython might grow over time and the minimum requirements might increase, thus it is not a bad idea to leave some space for future updates. Being stuck to an older version of micropython because the controller runs out of RAM or ROM is kind of disappointing.

As my contribution to MicroPython project goes along the lines of researching and proving that it's possible to develop, and hopefully maintain, unbloated very high level language implementation, I'd like to take a chance to rebut the claims above.

First of all, regarding "new" and "old" versions. I would like to start with resetting the baseline by saying that new versions of most software don't bring any useful changes. Mostly, they bring flip-flop style of changes and features not really needed by users. There're purely marketing matters behind this, and certainly, there's nothing terribly wrong with it, except that there should be software developed in different way. Regarding specifically MicroPython, it just implements "Python" language, so there's only so much you can add to it (regarding the core language). And some argue that since 1.5.2, nothing unavoidably useful was added to core Python language either (if you disagree, then just make sure that you use, or at least know all the features which were in all the various versions). Standard library is another matter - CPython showed that it can grow uncontrollably. But that also points at the obvious solution - keep "standard library" at absolute minimum, and let all the rest be 3rd-party, community modules.

Finally, about possibility to increase minimum requirements over time. Again, there's no technical foundation behind that. Over time, byte keeps holding 256 values, and mark&sweep garbage collector stays the most size-efficient fully dynamic memory management scheme. There can be maintenance issues keeping the minimum at minimum, that's why I brought this as one of the first issues when started contributing: RFC: Configurability and parametrization. Damien is positive about that approach, so there are all chances for MicroPython to be unlike most of the other software projects: all of unbloated, efficient, and real-world useful.