MicroPython and the European Space Agency(forum.micropython.org)
forum.micropython.org
MicroPython and the European Space Agency
http://forum.micropython.org/viewtopic.php?f=8&t=744
5 comments
NASA has been using Python for awhile apparently too: https://www.python.org/about/success/usa/
Great news for the Python community.
Python is actually widely used in scientific community, guys working on data analysis from CERN LHC are heavily relying on Python + NumPy + SciPy for their work as well.
It's easy to learn and makes data analysis really easy with "batteries included" approach (and costs way less than often problematic and buggy MatLab on Linux).
It's easy to learn and makes data analysis really easy with "batteries included" approach (and costs way less than often problematic and buggy MatLab on Linux).
PANDAS really is a great thing
From that link it seems that Python is used at NASA exclusively in ground-based systems. In contrast, the MicroPython+ESA collaboration is supposedly also looking at using the language in "payloads", ie things that go into space.
Naive question: wouldn't lua or scheme be more suitable than python to be embedded in microcontrollers?
It's not like ESA has commissioned them to start work on a python implementation for microcontrollers from scratch. Micropython already exists and works.
Previous discussion: https://news.ycombinator.com/item?id=7840566
Previous discussion: https://news.ycombinator.com/item?id=7840566
Just because it works doesn't mean it is the right solution of course.
There really isn't a best or better choice, everything has pros and cons. MicroPython is really nice in that you can write a C (or even inline assembly) extension to the language easily and get access to the low level hardware. It's very similar to writing a C extension with CPython.
I too wonder why ESA and NASA have chosen Python over JavaScript or Lua? The later has been especially design from the ground up for that task. It probably has to do with that their engineers already know Python and Python has a C API too.
I feel like regardless of how ubiquitous Javascript is, it's honestly an awful choice for embedded applications (no, most embedded applications don't sport some racecar ARM A7/A8/A9/A15, and shouldn't if it's not absolutely necessary); there are excellent reasons C still dominates here, and would likely be replaced with something like Rust instead of JS. Manual memory management is usually a huge plus on lots of embedded platforms, static typing is really important here, and most of the code is rather low level. These concerns are really sort of exacerbated on stuff going up into space, as the chips tend to be lower density designs, and simpler. Forth is an excellent choice here, and Lua if whatever you're running on can spare some extra CPU cycles. I guess it will be interesting to see how things pan out with MicroPython.
I would imagine if you could do anything to improve on what exists today for embedded, it would be to push things like verifiable systems harder, kind of what like Margaret Hamilton was pushing with USL[1].
[1] - http://en.wikipedia.org/wiki/Universal_Systems_Language
I would imagine if you could do anything to improve on what exists today for embedded, it would be to push things like verifiable systems harder, kind of what like Margaret Hamilton was pushing with USL[1].
[1] - http://en.wikipedia.org/wiki/Universal_Systems_Language
Perosnally i think there's a niche for higher level languages(maybe python) in the non cost-sensitive embedded genre, for systems where size, determinism, peripherals, and maybe power makes embedded micro-controllers attractive - without aiming at low-cost.
And i would guess that there are plenty of developers doing such work , either in research or small volume products(or maybe even medium volume).
And i would guess that there are plenty of developers doing such work , either in research or small volume products(or maybe even medium volume).
Even if you decide that an extra $X dollars is fine to tack onto the price of whatever it is you're shipping, being as updates are as difficult as they are in the field for an embedded device, I still think I'd rather stick with a statically typed language with good testing and verification tools (granted you can blow your foot off with C too, but there's a lot of talent around here for building safety critical system in C--Javascript not so much). It's not just the upfront cost where something like Javascript has the potential to hurt you here.
what you say does make sense. if you care about reliability ,python isn't that good.
but what would be the ideal reliability solution ? I'm thinking rust + freescale chips and low levels libraries(high quality) + some form of community ,like the mbed for higher level code,but where contributions(in rust) are required good testing support. plus maybe some form of reuse for real-time blocks like xcore/xmos enables.what do you think about that ? what's your ideal solution for reliability?
but what would be the ideal reliability solution ? I'm thinking rust + freescale chips and low levels libraries(high quality) + some form of community ,like the mbed for higher level code,but where contributions(in rust) are required good testing support. plus maybe some form of reuse for real-time blocks like xcore/xmos enables.what do you think about that ? what's your ideal solution for reliability?
I would have assumed Ada would be a popular choice in this domain, due to its improved safety over C. I know it's popular for aerospace.
Yeah, it kind of slipped my mind, but Ada is another good choice.
Unfortunately, Ada isn't a 'cool' language any more, so it's hard to get a new generation of programmers interested in it. Even university programs that should know better are teaching almost exclusively in languages that have no business anywhere near safety critical environments.
Sometimes getting things done is far more important than trying to get them done with the most optimal tool, particularly if choice is somewhat subjective.
I'm not sure that is a naive question. The answer is yes.
Yes, but the scientists who write the software are not necessarily accomplished programmers so they tend to favor nicer syntax over efficiency.
Does someone know about what SPARC processors they are talking about? I thought (at least for long-range missions) RAD-hardened PowerPC processors where the way to go.
Theres a nice explanation here on why they chose them - http://space.stackexchange.com/questions/729/why-did-the-esa...
The linked material in the answer is also higly interesting, including details about the RAD-hardening. As the decision was made in 1991 to use the SPARC architecture, it makes sense that they continued the development of their architecture. It is also good to see that there seems to be VHDL code available to tinker with the core in FPGAs. Thank you for the link :)
The ERC32 + LEON (SPARCv7/8) range of rad hard microprocessors developed under contract from ESA. Non fault tolerant versions of LEON are available as open source VHDL. See www.gaisler.com.
Radhard PowerPC are thing of the past I think. No development since the BAE RAD750?
Radhard PowerPC are thing of the past I think. No development since the BAE RAD750?
Could be LEON, which is still closely associated with the ESA: http://en.wikipedia.org/wiki/LEON
If MicroPython is the opposite of Monty Python, then is the European Space Agency the opposite of the Holy Grail?
One of the reason why python is easy to get going is extensive documentation, especially at python.org.