Micropython

[Oleg_Hahm]

Hey rioters,

has anyone heard about Micropython[1] yet? Seems like an interesting project and I would love to give it a try on RIOT. There's "STM version" version that comes with "stmhal", so I guess it shouldn't be too difficult (sic!) to port it to RIOT. However, I guess it makes only sense for some of the more powerful boards, since the stmhal firmware already consumes almost 300kB ROM and 30kB RAM.

Cheers, Oleg

[1] http://micropython.org/ [2] http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260000

[David_Lyon]

If you want to do python, sure that's ok.

I've done a lot of Python programming and just come to the personal conclusion that it's not as nice to develop in for an embedded device as is C++.

If somebody really tries hard (and knows Python), it's possible to get C++ to be not too much bigger than Python in code length.

Here's an example I wrote of an IoT switch: https://github.com/clixx-io/clixx.io/blob/master/examples_eventframework/remoteswitch/remoteswitch.cpp

That's in C++, all it does is switches a GPIO pin On/Off when an IoT message "On" / "Off" is received.

I haven't found a way to do it as nicely in Python as C++. And there are many devices where Python is never going to be an option such as the MSP430/AVR/PIC. Add to that, one IoT customer requirement can be ultra-low power - running on a solar cell etc.

That's just my 2c

David

[miri64]

Hi, Appart from web projects or an “advanced calculator” I use python primarily as means to prototype an idea I have (or if shell script would be just too complicated ^^) and then go to C (others probably would go to C++, but that is a matter of personal taste, I think), if I need performance, so for this (and as a low entry point for absolute beginners) I would welcome python (or some other easy-to-learn scripting language) as a feature in RIOT.

As I am a huge Python fan-girl and for arguments sake I felt inclined to provide a similar example as presented by David. But since I do everything embedded in C and everything else is not really comparable, I envisioned how something similar as David’s example could look like in a dreamed-up RIOT-ported (micro)python (assuming we map RIOT modules to python modules) :-D: https://gist.github.com/authmillenon/cf748f9525d8a3cfa34e (mind that the RIOT.thread module might even be replaced by a RIOT-specific implementation of python’s own threading module)

An eyewinkling cheers from, Martine

PS: Mind that micropython is completely written in C and the RIOT-backend would probably also be written in C, so I’m not sure how valid the size argument is without in-depth testing.

[Oleg_Hahm]

Hi!

I haven't found a way to do it as nicely in Python as C++. And there are many devices where Python is never going to be an option such as the MSP430/AVR/PIC. Add to that, one IoT customer requirement can be ultra-low power - running on a solar cell etc.

That's probably true and I'm not sure either if things like micropython or elua will be really useful for IoT applications in the end, but I envision it more as a kind of "advanced configuration" possibility. That means, that the whole system is written in highly efficient C or C++ code, but giving the application the possibility to execute python code to perform easy modifications of the system's behavior at runtime in cases where real software updates are not feasible/desirable and the simple replacement of some parameters is not enough.

All in all, I'm just curious how things like that would perform on RIOT on IoT device.

Cheers, Oleg

[David_Lyon]

.. I need performance, so for this (and as a low entry point for absolute beginners) I would welcome python (or some other easy-to-learn scripting language) as a feature in RIOT.

True. And if you look at some Python<->C networking performance comparisons, Python can come out ahead of C. All the best webservers are no longer written in C, afaik.

I envisioned how something similar as David's example could look like in a dreamed-up RIOT-ported (micro)python (assuming we map RIOT modules to python modules) :-D: https://gist.github.com/authmillenon/cf748f9525d8a3cfa34e [3]

Definitely!

I actually assembled my C++ EventFramework after seeing/using circuits · PyPI

As a micro-python option, there's also LUA. Which is already popular on Routers. It's not as memory or stack hungry. It's halfway between Python and C++. LUA just doesn't have the wow factor of Python for me unfortunately. But it would be better suited imho than Python and known to work on small processors.

Python would be a very good language to have as a friend of Riot, but there are *so* many compatability issues to solve downstream Operating-System wise, ie filesystems, databases, timers, pyrserial. I just can't see enough of those basic pythonic functionality items implemented for Python to be viable.

Unless that is, the 'Python for DOS' concept is used as a starting point.

One other way, is to say, 'ok, everything else can run Python (our notebooks/phones/pc's) and we'll use that to talk to our Riot devices'.

In that case things are much simpler.

But to restate, having small code applications like https://gist.github.com/authmillenon/cf748f9525d8a3cfa34e is the way to go. Nobody has 3 weeks to code stuff these days and small, fast and short is a great way to go.

Regards

David

[Kaspar]

Hi,

[David_Lyon]

I looked again at your example and took the opportunity to do some trimming. The python goes to 21 lines in length and I could get the C++ down to 22 lines of code. So I would say, directly comparable?

The advantage of the C++ is that it would run on Linux and anything with GCC such as the MSP430, whereas the Python will only run on the larger machines.

[mcr]

While I’m not a python fan, I acknowledge the power that it has for newbies. The pull request from 2015 for RIOT-OS port has yet to be merged. I imagine it needs rebasing from both the RIOT-OS and Micropython sides.

Long thread here about C/C++/micropython, and it’s not about lines of code. It’s about allowing newbies to do useful things without shooting themselves in the foot quite so easily. A reason I’d want to run micropython on RIOT-OS is because the other RTOS haven’t got particularly good networking. Depending upon which branch, you probably get no IPv6, no RPL, CoAP, etc.

What I’d like to see is a way to delve into the RPL, IPv6 and CoAP pieces from micropython. But, I’m actually totally ignorant on how to do networking with micropython, on RIOT-OS. “import network” doesn’t work. So what does work?

[emmanuelsearch]

@mcr did you take a look at the example which pulls in this micropython fork from @Kaspar which has support for some RIOT apis? (xtimer, adc, GPIO iirc)

[emmanuelsearch]

(no network support that I know of so far though)

[mcr]

@Karpar’s pull request into micropython is 6 year old. It was last touched two years ago when we pulled in the code, but what about the flow of patches the other way?

[kirk]

I used micropython on M3 boards for a major dGPS trial in Iceland… as it is so much easier to patch in the cold/rain. It would be great to have RIOT on a board doing serious stuff like CoAP coms and schedule but have a page of micropython for the top level code Ideal on a dual core rp2040 I think!!

[emmanuelsearch]

@mcr as discussed during your (nice!) presentation at the Summit on related topics, we’d really love to accommodate your current & future enhancements to microPython support in RIOT asap. If I understood correctly you have upgraded to most recent microPython, and you plan to add gnrc support, which is awesome. What would you (and/or Yoichi) recommend we set up, so as to improve and speed-up our workflow maintaining and developing microPython support in RIOT (which is currently based on a semi-obscure branch from @Kaspar)?

[j-devel]

Thanks @emmanuelsearch for arranging this discussion regarding micropython support in RIOT!

I think having a new RIOT org fork of micropython is a good idea. There, we can consolidate all the progress made by Kaspar and our recent enhancements. Also, we can be progressively adding missing components (e.g. networking modules) to the fork.

Now, I would like to recap what we have at hand, and propose what I think a feasible workflow for migration.

In the summit’s demo, we used our fork via this example endpoint, where our fork roughly consists of the following three commit groups:

1. miscellaneous enhancements (build fixes, native/esp32 board switching, etc.)
2. Merge branch ‘add_riot_port’ of https://github.com/kaspar030/micropython
3. https://github.com/micropython/micropython/tree/v1.16

I realise that “commits 1)” needs cleanup (i.e. removing our demo specific code), so I would like to do that. After that, for migration, I think we can try to

• reflect all the commits 1-3) against the RIOT org fork of micropython, then finally,
• update the RIOT’s example endpoint

Does this workflow sound reasonable?

[benpicco]

I would hope that the RIOT port could eventually be integrated upstream so we don’t have to maintain a fork forever.

MicroPython already has ports to Linux, Windows and Zephyr along with all the bare-metal targets - I’m sure they don’t mind a RIOT port if it’s well contained.

[mcr]

@emmanuelsearch

If I understood correctly you have upgraded to most recent microPython, and you plan to add gnrc support, which is awesome.

I think that our efforts to do gnrc will get deferred until after we have it working with lwip on all platforms.

What would you (and/or Yoichi) recommend we set up, so as to improve and speed-up our workflow maintaining and developing microPython support in RIOT (which is currently based on a semi-obscure branch from @Kaspar)?

We need to get it upstreamed. I guess we’ll be creating a new pull request to micropython for that. I’ll try to get that done in the next two weeks.

[emmanuelsearch]

@mcr @jdevel thanks for your joint input on this! Just to make sure we get your point @mcr are you of the same opinion with @jdevel that (i) consolidating to a new RIOT org fork is useful for you at this point and (ii) it does not hurt your plans to upstream? (Upstreaming whatever makes sense to micropython is definitely a good plan.)

[mcr]

@emmanuelsearch

@mcr @jdevel thanks for your joint input on this! Just to make sure we get your point @mcr are you of the same opinion with @jdevel that (i) consolidating to a new RIOT org fork is useful for you at this point and (ii) it does not hurt your plans to upstream? (Upstreaming whatever makes sense to micropython is definitely a good plan.)

@jdevel is doing the work. I think that if the pull request comes from RIOT-OS, that it will be a good thing.

[mcr]

Email asked us what next: I think that @jdevel needs to get access to https://github.com/RIOT-OS/micropython (or make a pull request against it), and then we redo/update the pull request to upstream.

[j-devel]

@emmanuelsearch Thanks for your support. It would be great if you help create branch “v1.17-riot” in https://github.com/RIOT-OS/micropython. I will try to file a PR against it; then we refine it as @mcr suggested.