MicroPython, a few years on(kickstarter.com)
kickstarter.com
MicroPython, a few years on
https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers/posts/1502594
31 comments
As someone who fits the description:
1. A non-negligible amount of physics research involves programming. Analyzing large amounts of data in ways that (hopefully) no one has ever considered before is not something you can easily do by hand anymore.
2. Physicists are taught to see the world as reductionists: complex systems are broken down into smaller, more understandable parts. Hell, most of physics is reducing things to take advantage of symmetries, or approximate interactions as harmonic oscillators (springs), or a small number of other very well understood/studied phenomena. The hard part is making sure your reductionist assumptions and approximations are correct.
3. High-end physics research positions at universities are very few and far between (and are very much a boys club of nepotism with regards to hiring), and even those don't offer the kind of compensation that you see for mid-level software developers in tech companies.
4. After you've learned how to read & interpret publications in physics research, most computer science papers seem tame in comparison.
Incidentally, the reasons I described above are also why many physicists end up being hired by investment banks or hedge funds. Out of all the people from university I still keep in touch with, I think only one of them is doing actual research in physics. The rest are working in tech or at a bank/fund.
1. A non-negligible amount of physics research involves programming. Analyzing large amounts of data in ways that (hopefully) no one has ever considered before is not something you can easily do by hand anymore.
2. Physicists are taught to see the world as reductionists: complex systems are broken down into smaller, more understandable parts. Hell, most of physics is reducing things to take advantage of symmetries, or approximate interactions as harmonic oscillators (springs), or a small number of other very well understood/studied phenomena. The hard part is making sure your reductionist assumptions and approximations are correct.
3. High-end physics research positions at universities are very few and far between (and are very much a boys club of nepotism with regards to hiring), and even those don't offer the kind of compensation that you see for mid-level software developers in tech companies.
4. After you've learned how to read & interpret publications in physics research, most computer science papers seem tame in comparison.
Incidentally, the reasons I described above are also why many physicists end up being hired by investment banks or hedge funds. Out of all the people from university I still keep in touch with, I think only one of them is doing actual research in physics. The rest are working in tech or at a bank/fund.
[deleted]
Maybe a deeper sense of 'applied' science if you program your experiments ?
I mean absolutely no disrespect and wish everyone well in this project, but other than a fun hobby or even more fun career for the author, what is the use case for MicroPython? Surely at the microcontroller level, C is perfectly adequate and already in place, everywhere?
Excellent questions. First, there is the complexity of setting up a cross-development environment for your chosen controller. Take the 8-bit AVR's as found in Arduino. I was using those before Arduino, and frankly didn't see the point of Arduino. But then given my prior experience it was not much of an issue for me to set up a good cross-dev environment and write C to the bare-metal, and pretty soon was sending patches to gdb-avr. But... the magic of Arduino, I see now, was that it created an approachable development environment for AVR's that was friendly to people that didn't come to AVR's ready to patch gdb to their liking.
Now fast-forward to today, when 8-bit controllers are pretty much a thing of the past and ARM Cortex-Mx processors are the way to go. Setting up C/C++ cross-development is a bit more challenging. Writing enough code to get out of reset, get your I/O mux'es set, and actually wiggle an output pin is a lot of work. What Micropython does is turn a USB cable into a development environment that allows you to try things on an ARM a few minutes after your PyBoard arrives in the mail. It also provides a BSD-licensed base of code that works with a well-defined and easy to install build chain so that you can reflash the part with a custom build of your liking. So for the performance-critical parts, you can write a C extension, if it comes to that. But a little bit of in-line assembly (which Micropython supports) might be all you need.
TL;DR: You can avoid a lot of time-consuming heavy lifting and focus your energy on the part that matters to you, accessible through a very powerful language.
I'm admittedly a Micropython partisan. But FWIW I have been doing embedded development off-and-on since the 6502 was the hot new chip (yes, gray beard and all) and to me Micropython is the most interesting development in embedded development since Arduino.
All that said: Is it really a viable way to ship a commercial product? I say yes: 1. The licensing is there. 2. You can easily write C extensions for the performance critical parts. 3. Python should give you time-to-market advantages over C-on-the-bare-metal.
Now fast-forward to today, when 8-bit controllers are pretty much a thing of the past and ARM Cortex-Mx processors are the way to go. Setting up C/C++ cross-development is a bit more challenging. Writing enough code to get out of reset, get your I/O mux'es set, and actually wiggle an output pin is a lot of work. What Micropython does is turn a USB cable into a development environment that allows you to try things on an ARM a few minutes after your PyBoard arrives in the mail. It also provides a BSD-licensed base of code that works with a well-defined and easy to install build chain so that you can reflash the part with a custom build of your liking. So for the performance-critical parts, you can write a C extension, if it comes to that. But a little bit of in-line assembly (which Micropython supports) might be all you need.
TL;DR: You can avoid a lot of time-consuming heavy lifting and focus your energy on the part that matters to you, accessible through a very powerful language.
I'm admittedly a Micropython partisan. But FWIW I have been doing embedded development off-and-on since the 6502 was the hot new chip (yes, gray beard and all) and to me Micropython is the most interesting development in embedded development since Arduino.
All that said: Is it really a viable way to ship a commercial product? I say yes: 1. The licensing is there. 2. You can easily write C extensions for the performance critical parts. 3. Python should give you time-to-market advantages over C-on-the-bare-metal.
Excellent summary and some good points made, thanks.
First, someone might prefer python on a microcontroller for the same reasons one might prefer python on any other system: interactive development, clean string and list handling, no need to explicitly manage memory, familiarity with the language ...
Now that one can buy a 100+ MHz 32b CPU with 256KB RAM and 1MB of FLASH for $5 (and dropping), using assembly or C to make it fit into an 8b PIC with 2KB of RAM to save $3 isn't a worthwhile trade off for many applications.
Now that one can buy a 100+ MHz 32b CPU with 256KB RAM and 1MB of FLASH for $5 (and dropping), using assembly or C to make it fit into an 8b PIC with 2KB of RAM to save $3 isn't a worthwhile trade off for many applications.
My question is "why not Lua"? I can see why someone would like to program on a higher level scripting language instead of C and Lua is very much designed from the start to be lean, fast and embeddable. It also inter-operates very easily with C.
Because some people disagree that Lua is nice language. Lean-ness is questionable, e.g. BrainFuck is much more "lean", so what? MicroPython can be built to the same binary sizes as a typical Lua build, and yet offer more language features. Lua's embedability has stronghold in games, that's where it usually embedded. Embedded hardware systems are a little different beasts. For them, it's helpful to differentiate e.g. integer from float number (Lua's numbers are floats, it took Lua a long way to acquire a standard module to do bitwise operations, which some people consider just an ugly hack). Also, helpful to differentiate arrays with guaranteed O(1) access from dictionaries (Lua has some mutant container type about whose behavior you can never be sure).
Lua 5.3 released recently and has integers and bitwise operators. Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array.
That's what I mean - recently. With more than 20-year Lua history, finally recently adding bitwise operations to the core language is move welcomed by Lua community. No talking about the fact that Lua authors still can't find right pattern for modules, so in 5.3 they smashed how it was in 5.2 and few previous versions (and that's not the 1st time IIRC), and welcomed community to redo their homework on that part. That only emphasizing the fact that Lua is intended for adhoc embedding, like, you put it in your game, wrap your game's objects. Anything else - well, depends. Changes in 5.3 is a reason why a lot of community is on 5.2. (Well, to be fair, there's Python2/Python3 split too, MicroPython is Py3.)
> Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array.
Right, if you don't have "holes", if you start array indexing from arbitrary number (it would be cool to start indexing from e.g. Pi btw, too bad Lua isn't orthodox enough to do that ;-) ), then it's O(1). Otherwise, it's phase of moon dependent (pun intended).
> Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array.
Right, if you don't have "holes", if you start array indexing from arbitrary number (it would be cool to start indexing from e.g. Pi btw, too bad Lua isn't orthodox enough to do that ;-) ), then it's O(1). Otherwise, it's phase of moon dependent (pun intended).
Look up the Barracuda Application Server. It's commercial but has Lua for dynamic stuff. Runs on reliable microkernels, too. One worth cloning with FOSS.
Lua is on the market for much longer time, and of course it's used in many products. It's my personal belief though that in many places Lua is used, it's used for the lack of alternative. And one of my motives for working on MicroPython is to provide such better alternative. It's the same liberal license, but has that "batteries included" stroke (mind that for MicroPython, there're "coin-sized" batteries included ;-) ), i.e. out of the box it comes with many features with nice standard API, which for Lua must be provided separately (invented and reinvented?). The key of this effort is of course sustainability, and we're making plans how to be around for a long time ;-).
All in all, we're on the same playing field, and welcome independent reviews of MicroPython vs Lua.
All in all, we're on the same playing field, and welcome independent reviews of MicroPython vs Lua.
Nice explanation. To be clear, I was just citing a use of Lua in embedded rather than promoting it. I don't use it. Since you brought it up... :P
...the advantage was predictability, simplicity, performance, extensability, and tiny memory footprint. The simplicity, predictability, and performance are where Python was a no-go for embedded. So, those are the areas you need to focus on in your implementation to get parity or beat it.
Plus, these traits of Lua are a pre-requisite to high-assurance systems that take things to next level. I've considered a medium or high assurance Python a number of times. Language and implementation were too complex for me to even start. So, I welcome a simpler take on language that others might take to another level.
...the advantage was predictability, simplicity, performance, extensability, and tiny memory footprint. The simplicity, predictability, and performance are where Python was a no-go for embedded. So, those are the areas you need to focus on in your implementation to get parity or beat it.
Plus, these traits of Lua are a pre-requisite to high-assurance systems that take things to next level. I've considered a medium or high assurance Python a number of times. Language and implementation were too complex for me to even start. So, I welcome a simpler take on language that others might take to another level.
FYI, there was an update on currently running MicroPython ESP8266 kickstarter about reverse engineering and open-source aspects of ESP8266 chip. Some people say it's good. I tried to post it on HN, but it didn't catch momentum: https://news.ycombinator.com/item?id=11174534 . Maybe readers of this thread find it interesting though.
Can micropython be used to make Android apps?
For regular Android apps using Python you might want to look into Kivy: https://kivy.org/docs/guide/android.html
first, lets be clear about Micropython, the software versus PyBoard, the reference hardware. Micropython on a Pyboard is runnunig on bare metal with no OS. Micropython is very portable, and builds nicely on Linux, yielding a nice small-footprint Python. I am not aware of a build for Android, but it seems like it should be straightforward. Everything about Micropython is tuned for low memory footprint, so it might be a great tool for Android aps.
But Android is based on Linux, i.e. it wouldn't allow MicroPython to run directly on the bare metal.
So that would seem to make actual Python a better candidate for Android porting. I found http://qpython.com/ which seems interesting, but the site didn't look finished.
So that would seem to make actual Python a better candidate for Android porting. I found http://qpython.com/ which seems interesting, but the site didn't look finished.
Python indeed runs fine on Android once you can get it to compile (the interpreter needs to be patched to compile with bionic, or can be compiled without patches using the CrystaX NDK). The Kivy graphical framework has the associated python-for-android project [1] taking care of doing this plus including other components like Python modules (including complex ones like numpy) and can compile with different kinds of backend (not just Kivy). There are also other projects running Python on Android in different ways.
[1] https://github.com/kivy/python-for-android
[1] https://github.com/kivy/python-for-android
Yes, it would run on Android the way it runs on Lunux, as an OS process. The benefit is extreme parsimony with respect to RAM use.
I started Android port: http://forum.micropython.org/viewtopic.php?f=15&t=898 . It's primary goal not to make normal Android apps (.apk's), but to access Android APIs from command line (like adb). Here's quick example what it can do: https://github.com/pfalcon/micropython-projs/tree/master/and... . I also have an OpenGLES example someone which turns out I missed to push. Of course, I though about making "normal" apps too, but that would be a long way and bunch of effort.
With ESP8266 port kickstarter, Android port is put on hold.
With ESP8266 port kickstarter, Android port is put on hold.
You'd be better off trying to to use Jython (which compiles Python to JVM bytecode) because that would give you interop with Android's Java libraries.
I'm not aware of anyone having succeeded with Jython - I think there are technical issues but I'm not sure what's the nature of the problem.
One option for interacting with java from python is to use tools like pyjnius (http://pyjnius.readthedocs.org/en/latest/) - this is what e.g. Kivy does to get system information like screen metrics.
One option for interacting with java from python is to use tools like pyjnius (http://pyjnius.readthedocs.org/en/latest/) - this is what e.g. Kivy does to get system information like screen metrics.
MicroPython Android support mentioned above is exactly inspired by pyjnius. My initial interest for uPy Android is to just hack on Android, not produce walled-garden (APK) apps. But I intended to post about this effort on Kivy list to see if someone might be interested. The idea might be to have something small, like https://love2d.org/ , but in Python. Note that I myself not really interested in cloning love2d, but if some readers of these comments would find idea interesting and could spread the word to Kivy circles, that would be appreciated (you never know what may come up if wide community gets involved - that's the beauty of Open Source).
You could likely interface with Android using MicroPython's wifi interface (which will almost certainly be included in the upcoming ESP8266 release) or using the micro:bit's Bluetooth Low Energy link.
What is it with physicists and programming? I know at least 3 people who started having physics degrees, but left it completely for programming. Mind you they are all excellent coders and sharps as hell... but this is not an uncommon profile it seems.