Page 1 of 2

another python on micorcontrollers project

Posted: Mon Mar 16, 2015 11:20 am
by Turbinenreiter
https://www.kickstarter.com/projects/13 ... duino-udoo

What they do is have a VM on the micro and cross-compile on a PC. And they run on ChibiOS. And they want to release under GPL3.

Re: another python on micorcontrollers project

Posted: Mon Mar 16, 2015 7:13 pm
by cloudformdesign
Have they heard of micropython? Why create a completely separate project doing the same thing?

Re: another python on micorcontrollers project

Posted: Mon Mar 16, 2015 8:16 pm
by blmorris
I had the same questions. They do acknowledge MicroPython, in a list of other similar projects successfully by Kickstarter.

It also looks like a different enough project with distinct design goals. The microcontroller application they are developing is purely a Python virtual machine running on top of an RTOS (ChibiOS). Unlike MicroPython, they aren't implementing a Python compiler on the microcontroller - the Python compiler is part of the IDE that runs on the desktop. This has some advantages - they can run their byte code on a smaller uC, and they can support any uC already supported by ChibiOS (assuming it has enough power to run the VM + application). Much more of an Arduino-like approach.
It also means that they lose the REPL and the ability to test and debug code directly on the uC which MicroPython provides.
I'm guessing that there is room for coexistence - I'll certainly be sticking with MicroPython for now.

Re: another python on micorcontrollers project

Posted: Tue Mar 17, 2015 10:43 am
by Turbinenreiter
the Python compiler is part of the IDE that runs on the desktop
I think this is something Micro Python could do, too.

Re: another python on micorcontrollers project

Posted: Tue Mar 17, 2015 1:13 pm
by bmarkus
For sure there is a room for several Python implementations for microcontrollers. What is great in MicroPython it sticks to the original Python philosophy I mean interactivity, no separate compilation, what is good for rapid prototyping, hobby projects, etc. On the other hand a traditional cross toolchain may fit better to a product than MicroPython where no need for a terminal, you want to run code from Flash instead of RAM and on a less powerful processor to save cost, at least now. Projects may bring up new ideas beneficial for others.

In the past there were already Python projects, most of them died before beeing usable, were not sexy enough or simply author lost interest and moved to other direction, like

http://blog.flyingpic24.com/category/python/
https://code.google.com/p/python-on-a-chip/
http://www.circuitsforfun.com/pymcu.html


What seems to be interesting and live is OWL

http://embeddedpython.org/
https://www.usenix.org/system/files/con ... inal30.pdf

Re: another python on micorcontrollers project

Posted: Tue Mar 17, 2015 11:07 pm
by pfalcon
blmorris wrote:This has some advantages - they can run their byte code on a smaller uC, and they can support any uC already supported by ChibiOS (assuming it has enough power to run the VM + application).
Well, it all depends on an angle of view. Someone would say "they can support any uC already supported by ChibiOS", but someone else would say "they're limited by supporting only ChibiOS (and devices supported by it)". Unlike Viper, MicroPython is fully portable and doesn't depend on any particular RTOS or OS. That means that MicroPython can run with any OS or RTOS. And indeed, there're existing port to POSIX, Linux, MacOS, Windows, FreeRTOS, NuttX. Port to to any other OS or RTOS can be done at any time, the only prerequisite is someone needing it (up to a level of doing a port or hiring someone else to do it), initial effort investment to get something running is about one man-week.

But as simple as 2+2, to run MicroPython with RTOS, you need to have both MicroPython and RTOS in flash, and RTOS will also take some RAM for itself. That's why MicroPython supports running without any RTOS. So, by definition it requires less resources, and can work with smaller MCUs, than an implementation which is chained to an RTOS.

The only way some other implementation can be smaller than MicroPython is by compromising on Python compatibility. MicroPython itself has to compromise on that, but any other small implementation I saw isn't even a Python, it's just some language which uses whitespace for indentation and whose keywords have various levels of similarity to Python keywords.

Re: another python on micorcontrollers project

Posted: Tue Mar 17, 2015 11:22 pm
by pfalcon
One thing I usually check is Python exception support. And none of the existing implementations has something which can be classified as real Python exceptions. I'll tell you why - because it's hard to implement them (you need design VM with them in mind, and then spend bunch of nights to debug them). And I'm not surprised at all that Viper doesn't have real exceptions either. But exceptions are required to write robust Python programs (and Python is about writing robust programs). No exceptions - no Python.

So, MicroPython's aim is to let people who know Python to program even the smaller devices, while using all their knowledge and expertise (they won't find they can't do easy and reliable error recovery for example). It's aim also is to teach people who don't know Python - the real Python, not waste their time with some false lookalike. A schoolkid who played with MicroPython for few months will be ready to start writing Web/GUI applications for desktop/server, and by the time of college graduation, may have enough experience to get a good job in the industry.

Re: another python on micorcontrollers project

Posted: Wed Mar 18, 2015 2:34 am
by blmorris
@pfalcon - I would have to agree with pretty much everything that you are saying here, especially regarding overall completeness of MicroPython as well as its portability. And we know it is portable because people are successfully porting it. You mentioned a few ports that I didn't know about, and then I remembered that it has also been ported to the TI-Nspire calculator too!
When I said that it (Viper) could run on a smaller microcontroller than MicroPython, I was thinking about the VM-only architecture they are targeting - I imagined that without the Python compiler and REPL implemented on the uC, the application could (potentially) be smaller even considering that it has to share resources with the underlying ChibiOS firmware. I don't actually know how big ChibiOS is, but I thought that it was fairly small.
-Bryan

Re: another python on micorcontrollers project

Posted: Wed Mar 18, 2015 7:32 am
by bmarkus
pfalcon wrote:One thing I usually check is Python exception support. And none of the existing implementations has something which can be classified as real Python exceptions. I'll tell you why - because it's hard to implement them (you need design VM with them in mind, and then spend bunch of nights to debug them). And I'm not surprised at all that Viper doesn't have real exceptions either. But exceptions are required to write robust Python programs (and Python is about writing robust programs). No exceptions - no Python.
It is a good point.

Re: another python on micorcontrollers project

Posted: Wed Mar 18, 2015 7:49 am
by bmarkus
ChibiOS does not support MIPS nor 8/16-bit PIC architectures.