MicroPython is a lean and fast implementation of the Python 3 programming language that is optimised to run on a microcontroller.
The European Space Agency (ESA) is funding further development of MicroPython. It is doing so to assess the suitability of the language for space-based applications, in particular for payloads.
WiPy 1.0 & 2.0, LoPy & SiPy are wireless MicroPython platforms sold by Pycom.
I'm using a Gatetel GT-HE910 series module which embeds the Telit modem including 3G, GPS, AD, IO and Python 2.7. This is used for a remote data aquisition application. Python is fairy slow on these modules but we only need an update every 15 minutes or in an alarm condition so they work well.
我的建议是 C 工具链适用于任何目标。 C 速度快、面向硬件、具有挑战性且有趣。 在嵌入式系统中坚持使用 C。 不需要安装配置愚蠢的 python 包来运行它。
Blockquote The only real problem I have in day to day work is that the last of static checking vs a regular compiler can cause problems to be thrown at run-time, e.g. a simple accidental cat of a string and an int in a print statement can bring the whole application down
To me it is a huge deal. Problems you could find at compile time and fix the problem now have to rely at run time. Not knowing the data type and having to write additional function just to check the datatype is hassle. There is no need to do that in C. How would you declare 'volatile' in python?
Blockquote The only downsides for embedded work is that sometimes python can be slow and sometimes it uses a lot of memory (relatively speaking). This hasn't causes us a show stopping problem yet, and python is quite easy to profile for both speed and memory if it becomes a problem.
This is also huge. For Embedded sytems or RTOS time constraint is very important.
Python is not necessary quick to code. It really depends what language you are comfortable with. Honestly it takes me 1 day to write function and unnecessary object orientation stuff which I can do in 2 hours in C. Testing is so inconvenient I have to write the code, py_compile, copy pyc in the target then run the program, then python quits complaining variable not defined or type cast error or some petty thing like that.
My suggestion is C toolchain is available for any target. C is fast, hardware oriented,challenging and fun. Stick with C for Embedded systems. No need to install configure silly python packages just to run it.
It works really well and is really easy to make custom code quickly - one of the strong points of python.
As for reliability of the code - we try to have 100% test coverage. Writing tests with python is very quick and it gives you a wonderful feeling of confidence. We use twisted trial to run the tests and report on coverage, but there are many other tools available.
In my experience python + tests is more reliable and much quicker to write than any other alternatives.
The only downsides for embedded work is that sometimes python can be slow and sometimes it uses a lot of memory (relatively speaking). This hasn't causes us a show stopping problem yet, and python is quite easy to profile for both speed and memory if it becomes a problem.
pychecker is a very useful too also which will catch quite a lot of common errors.
顺便说一句，请参阅这篇博文：“Python 的类型推断”，了解有关类型的有趣讨论推理和静态类型，包括一些 Guido van Rossum 博客文章的链接，这些文章描述了向 Python 添加可选的静态类型。
我同意 Bruce Eckel 的观点，即练习“强测试”比依赖强测试更好打字。 我认为这同样适用于嵌入式开发。
BTW, see this blog post: "Type inference for Python" for an interesting discussion of type inference and static typing, including links to some Guido van Rossum blog posts describing adding optional static typing to Python.
I agree with Bruce Eckel that one is better off practicing "strong testing" than relying on strong typing. I think that applies equally well to embedded development.
Personally, I've worked on some of the software that runs in the device used by BusRadio. It's an example of an embedded project built on Twisted and Python. The device is an embedded XScale processor running a debian-derived distribution, so it might not meet certain definitions of "embedded", but it is pretty dang small: it fits into the dashboard of a school bus.
There were some interesting issues with using Python with large libraries - the interpreter can take quite a while to start up and load all the code for Twisted on a really slow chip, and some things needed special-case optimizations. However, at no point was the dynamic nature of Python a problem. The software in question certainly wasn't perfect, but at least when using Twisted, a simple programming error will not "bring the whole application down". A traceback will get logged, and processing continues.
So, if you're in an embedded environment sufficiently unconstrained that you can use Python in the first place, it's no different than developing "regular" programs (games, desktop applications, web apps). You don't need static typing there, and you don't need it here either.
At my previous employer I had wanted to spend some time playing with building embedded systems in tinypy, which is a "minimalist implementation of Python in 64k of code". (But I never got to it and I no longer have time.)
I haven't tried them myself, so I don't know how the Python interpreter compares or differs from a PC implementation, such as which included modules, RAM and ROM memory limits, execution speed, etc.
However, as user foresightyj pointed out in a comment, it appears that they use Python 1.5.x, which is a truly ancient version, and so I would have trouble taking them seriously. Python developers would not enjoy downgrading to such an ancient version without so many modern Python features. I would be concerned about security issues with such an old version.
I've been working on microwave telecommunication equipments based on old and slow powerpc and 16Mb of RAM.
I've been able to port the Python 2.6.1 interpreter on VxWorks, in order to have the command line interpreter available directly from the target shell, or to execute python scripts uploaded to the target flash.
We used those scripts to perform autotest on the target or execute diagnostic procedures. Here some details on the whole procedure: HOW TO: Port Python to VxWorks
The only real problem I have in day to day work is that the last of static checking vs a regular compiler can cause problems to be thrown at run-time, e.g. a simple accidental cat of a string and an int in a print statement can bring the whole application down.
Unit tests are your only safety against these things.
Indeed, Python is often used as a 'support language' while you need to write some kind of tests - i.e. I was involved in a project, which (Python based) test framework code base was (is?) almost as big as that of the main product. Python 'agents' works on QNX, VxWorks - and most problems we have, was to port properly threading and network related parts of our code.
It might be worth to take a look OpenMoko project a lot of embedded development in Python is done there.
Things to watch-out: - support for Python/C extension module might behave quite strangely depending on platform/OS - most of embedded platforms offers quite out-dated versions of Python - finally you will find out that there is a difference between 'proper' embedded software in which every bit counts, and 'modern' embedded software that is performed on >412Mhz XScale CPUs with more thatn 128MB, and then Python just don't match the hardware that you would like to target :(
We use Python here at the university for embedded applications based on the Gumstix hardware platform. Although more capable than traditional embedded systems, we find the mix of small formfactor, low (ish) power consumption and the ease in transferring code between development on desktop machines and the target hardware invaluable.
Python is also a great language to teach the students, and with the Gumstix its great they can get code working on a low power system, rather than the headache and heartbreak that comes with using dedicated languages such as NesC.
我们开始用 Python 进行原型设计，但我们突然意识到它显然太慢了。 因此我们决定在不同的计算层构建程序，以达到速度要求。 C++ 是最好的解决方案。
为了同时使用 python 和 c++，我们必须严格控制输入。
My team wrote an embedded software made out of C++ and Python. We decided to write basic classes and heavy computational routines in C++. We wrote logic in Python. Boost libraries as glue. Using boost is never easy, but the results is excellent. Fast and easy to modify. Using python to represent the custom needings, we are able to satisfy customers' needings realtime, changing the code using injection technics. Something really exciting! (ok, I'm a geek ;)
We started prototyping in python but we suddenly realized that it was clearly too slow. So we decided to structure the program in different computational layers, in order to reach the speed requirements. C++ was the best solution.
In order to use python and c++ together we had to keep a strict control on typing.
顺便说一句，大部分设计和生产测试代码都是用 Python 编写的，主要在 PC 上的测试工具内运行。
I worked for a company which used Python on an embedded product based around an Atmel AVR32 and running embedded Linux. The firmware was initially developed on a PC (due to lack of a working hardware prototype), then later moved to the embedded hardware running on the cross-compiled Python interpreter.
The ability to debug and modify source code "live" on the device was a big plus during development, and saved a lot of time. The big disadvantages were speed and memory usage of the Python interpreter.
Following the first release of production firmware we ported critical sections of code over to C/C++. The porting effort was quite straightforward and resulted in an improvement of several orders of magnitude on speed-critical code (as you would expect).
Incidently most of the design and production testing code was written in Python, mainly running inside a test harness on a PC.
In my experience, Python has been traditionally used in desktop environments more than in the embedded field. There are two reasons, related to the fact that Python is interpreted:
C/C++ languages have higher performance than Python (and this is important in embedded systems with a slow microcontroller)
C/C++ languages have more deterministic response times (and this is important in real-time embedded systems controlling something).
Of course, as embedded systems will become faster and time-to-market shorter, Python will be more adopted in the embedded sector.
发布评论
评论（17）
我有一个 Python 服务器（使用 Twisted）和一些在 XP Embedded 下运行的帮助程序脚本，并且运行良好。
I have a Python server (using Twisted) and some helper scripts running under XP Embedded, and it's been working great.
最新进展
Recent developments
EVE Online 客户端不是实时、高性能 Python 的展示吗？
Isn't the EVE Online client a showpiece of real-time, high-performance Python?
我使用的是 Gatetel GT-HE910 系列模块，它嵌入了 Telit 调制解调器，包括 3G、GPS、AD、IO 和 Python 2.7。 这用于远程数据采集应用。 Python 在这些模块上速度相当慢，但我们只需要每 15 分钟或在警报条件下更新一次，这样它们就可以正常工作。
http://www.gatetel.com/#!gt-series/cscb
I'm using a Gatetel GT-HE910 series module which embeds the Telit modem including 3G, GPS, AD, IO and Python 2.7. This is used for a remote data aquisition application. Python is fairy slow on these modules but we only need an update every 15 minutes or in an alarm condition so they work well.
http://www.gatetel.com/#!gt-series/cscb
对我来说是一件大事。 您可以在编译时发现问题并修复问题，但现在必须依赖于运行时。 不知道数据类型并且必须编写额外的函数来检查数据类型是很麻烦的。 在 C 中不需要这样做。如何在 python 中声明“易失性”？
这也是巨大的。 对于嵌入式系统或 RTOS 来说，时间限制非常重要。
Python 不一定要快速编码。 这实际上取决于您熟悉哪种语言。 老实说，我花了 1 天的时间来编写函数和不必要的面向对象的东西，而用 C 语言我可以在 2 小时内完成。
测试非常不方便，我必须编写代码，py_compile，在目标中复制 pyc，然后运行程序，然后 python 退出抱怨变量未定义或类型转换错误或类似的小事情。
我的建议是 C 工具链适用于任何目标。 C 速度快、面向硬件、具有挑战性且有趣。 在嵌入式系统中坚持使用 C。 不需要安装配置愚蠢的 python 包来运行它。
To me it is a huge deal. Problems you could find at compile time and fix the problem now have to rely at run time. Not knowing the data type and having to write additional function just to check the datatype is hassle. There is no need to do that in C. How would you declare 'volatile' in python?
This is also huge. For Embedded sytems or RTOS time constraint is very important.
Python is not necessary quick to code. It really depends what language you are comfortable with. Honestly it takes me 1 day to write function and unnecessary object orientation stuff which I can do in 2 hours in C.
Testing is so inconvenient I have to write the code, py_compile, copy pyc in the target then run the program, then python quits complaining variable not defined or type cast error or some petty thing like that.
My suggestion is C toolchain is available for any target. C is fast, hardware oriented,challenging and fun. Stick with C for Embedded systems. No need to install configure silly python packages just to run it.
我们在很多带有 ARM 处理器的嵌入式板和 16 MB RAM（运行 Linux）。
它工作得非常好，并且非常容易快速编写自定义代码——这是 python 的优点之一。
至于代码的可靠性 - 我们尝试拥有 100% 的测试覆盖率。 使用 python 编写测试非常快，并且会给您一种美妙的自信感。 我们使用扭曲试验来运行测试并报告覆盖率，但还有许多其他工具可用。
根据我的经验，Python + 测试比任何其他替代方案更可靠且编写速度更快。
嵌入式工作的唯一缺点是有时 python 可能很慢，有时会使用大量内存（相对而言）。 这还没有给我们带来显示停止问题，并且如果出现问题，Python 很容易分析速度和内存。
pychecker 也是一个非常有用的工具，它可以捕获很多常见错误。
We use python in quite a lot of embedded boards with ARM processors and 16 MB of RAM (running linux).
It works really well and is really easy to make custom code quickly - one of the strong points of python.
As for reliability of the code - we try to have 100% test coverage. Writing tests with python is very quick and it gives you a wonderful feeling of confidence. We use twisted trial to run the tests and report on coverage, but there are many other tools available.
In my experience python + tests is more reliable and much quicker to write than any other alternatives.
The only downsides for embedded work is that sometimes python can be slow and sometimes it uses a lot of memory (relatively speaking). This hasn't causes us a show stopping problem yet, and python is quite easy to profile for both speed and memory if it becomes a problem.
pychecker is a very useful too also which will catch quite a lot of common errors.
顺便说一句，请参阅这篇博文：“Python 的类型推断”，了解有关类型的有趣讨论推理和静态类型，包括一些 Guido van Rossum 博客文章的链接，这些文章描述了向 Python 添加可选的静态类型。
我同意 Bruce Eckel 的观点，即练习“强测试”比依赖强测试更好打字。 我认为这同样适用于嵌入式开发。
BTW, see this blog post: "Type inference for Python" for an interesting discussion of type inference and static typing, including links to some Guido van Rossum blog posts describing adding optional static typing to Python.
I agree with Bruce Eckel that one is better off practicing "strong testing" than relying on strong typing. I think that applies equally well to embedded development.
就我个人而言，我开发了 BusRadio 使用的设备中运行的一些软件。 这是一个基于 Twisted 和 Python 构建的嵌入式项目示例。 该设备是一个嵌入式 XScale 处理器，运行 debian 衍生 发行版，因此它可能不符合“嵌入式”的某些定义，但它非常小：它适合校车的仪表板。
使用带有大型库的 Python 存在一些有趣的问题 - 解释器可能需要相当长的时间才能在非常慢的芯片上启动并加载 Twisted 的所有代码，并且有些事情需要特殊情况的优化。 然而，Python 的动态特性在任何时候都不是问题。 该软件当然并不完美，但至少在使用 Twisted 时，一个简单的编程错误不会“导致整个应用程序瘫痪”。 将记录回溯，并继续处理。
因此，如果您处于一个不受限制的嵌入式环境中，您可以首先使用 Python，那么这与开发“常规”程序（游戏、桌面应用程序、Web 应用程序）没有什么不同。 那里不需要静态类型，这里也不需要。
Personally, I've worked on some of the software that runs in the device used by BusRadio. It's an example of an embedded project built on Twisted and Python. The device is an embedded XScale processor running a debian-derived distribution, so it might not meet certain definitions of "embedded", but it is pretty dang small: it fits into the dashboard of a school bus.
There were some interesting issues with using Python with large libraries - the interpreter can take quite a while to start up and load all the code for Twisted on a really slow chip, and some things needed special-case optimizations. However, at no point was the dynamic nature of Python a problem. The software in question certainly wasn't perfect, but at least when using Twisted, a simple programming error will not "bring the whole application down". A traceback will get logged, and processing continues.
So, if you're in an embedded environment sufficiently unconstrained that you can use Python in the first place, it's no different than developing "regular" programs (games, desktop applications, web apps). You don't need static typing there, and you don't need it here either.
在我以前的雇主中，我曾想花一些时间在 tinypy 中构建嵌入式系统，这是一个“极简主义”用 64k 代码实现 Python”。 （但我从来没有做到这一点，而且我也没有时间了。）
At my previous employer I had wanted to spend some time playing with building embedded systems in tinypy, which is a "minimalist implementation of Python in 64k of code". (But I never got to it and I no longer have time.)
Telit 使 GSM/GPRS 调制解调器模块，包括 嵌入式 Python 解释器。
我自己没有尝试过，所以我不知道 Python 解释器与 PC 实现相比有何不同，例如包含模块、RAM 和 ROM 内存限制、执行速度等。
但是，正如用户 foresightyj 指出的那样在评论中，他们似乎使用Python 1.5.x，这是一个真正古老的版本，所以我很难认真对待他们。 如果没有这么多现代 Python 功能，Python 开发人员不会喜欢降级到如此古老的版本。 我会担心这样旧版本的安全问题。
Telit makes GSM/GPRS modem modules that include an embedded Python interpreter.
I haven't tried them myself, so I don't know how the Python interpreter compares or differs from a PC implementation, such as which included modules, RAM and ROM memory limits, execution speed, etc.
However, as user foresightyj pointed out in a comment, it appears that they use Python 1.5.x, which is a truly ancient version, and so I would have trouble taking them seriously. Python developers would not enjoy downgrading to such an ancient version without so many modern Python features. I would be concerned about security issues with such an old version.
我一直在研究基于旧的、缓慢的 powerpc 和 16Mb RAM 的微波电信设备。
我已经能够在 VxWorks 上移植 Python 2.6.1 解释器，以便直接从目标 shell 使用命令行解释器，或者执行上传到目标闪存的 python 脚本。
我们使用这些脚本对目标执行自动测试或执行诊断程序。
以下是整个过程的一些详细信息：如何：端口Python 到 VxWorks
I've been working on microwave telecommunication equipments based on old and slow powerpc and 16Mb of RAM.
I've been able to port the Python 2.6.1 interpreter on VxWorks, in order to have the command line interpreter available directly from the target shell, or to execute python scripts uploaded to the target flash.
We used those scripts to perform autotest on the target or execute diagnostic procedures.
Here some details on the whole procedure: HOW TO: Port Python to VxWorks
单元测试是抵御这些事情的唯一安全措施。
Unit tests are your only safety against these things.
事实上，当你需要编写某种测试时，Python 经常被用作“支持语言” - 即我参与了一个项目，该项目（基于 Python 的）测试框架代码库几乎与主要产品。
Python“代理”适用于 QNX、VxWorks - 我们遇到的大多数问题是正确移植代码中与线程和网络相关的部分。
可能值得一看 OpenMoko 项目，许多 Python 嵌入式开发都是在那里完成的。
注意事项：
- 对 Python/C 扩展模块的支持可能会表现得很奇怪，具体取决于平台/操作系统
- 大多数嵌入式平台提供相当过时的 Python 版本
- 最后你会发现“正确的”嵌入式软件和在大于 128MB 的 >412Mhz XScale CPU 上执行的“现代”嵌入式软件之间存在差异，而 Python 只是不这样做匹配您想要的目标硬件:(
Indeed, Python is often used as a 'support language' while you need to write some kind of tests - i.e. I was involved in a project, which (Python based) test framework code base was (is?) almost as big as that of the main product.
Python 'agents' works on QNX, VxWorks - and most problems we have, was to port properly threading and network related parts of our code.
It might be worth to take a look OpenMoko project a lot of embedded development in Python is done there.
Things to watch-out:
- support for Python/C extension module might behave quite strangely depending on platform/OS
- most of embedded platforms offers quite out-dated versions of Python
- finally you will find out that there is a difference between 'proper' embedded software in which every bit counts, and 'modern' embedded software that is performed on >412Mhz XScale CPUs with more thatn 128MB, and then Python just don't match the hardware that you would like to target :(
我们在大学使用 Python 来实现基于 Gumstix 硬件平台的嵌入式应用程序。 尽管比传统嵌入式系统功能更强大，但我们发现小外形尺寸、低功耗以及在台式机开发和目标硬件之间轻松传输代码的组合非常有价值。
Python 也是一种非常适合教授学生的语言，借助 Gumstix，他们可以让代码在低功耗系统上运行，而不必像使用 NesC 等专用语言那样头痛和心碎。
We use Python here at the university for embedded applications based on the Gumstix hardware platform. Although more capable than traditional embedded systems, we find the mix of small formfactor, low (ish) power consumption and the ease in transferring code between development on desktop machines and the target hardware invaluable.
Python is also a great language to teach the students, and with the Gumstix its great they can get code working on a low power system, rather than the headache and heartbreak that comes with using dedicated languages such as NesC.
我的团队用 C++ 和 Python 编写了一个嵌入式软件。 我们决定用 C++ 编写基本类和繁重的计算例程。 我们用 Python 编写逻辑。 将 Boost 库作为粘合剂。 使用 boost 从来都不是一件容易的事，但结果却非常好。 快速且易于修改。 使用Python来表示自定义需求，我们能够通过注入技术更改代码来实时满足客户的需求。 真是令人兴奋的事情！ （好吧，我是个极客；）
我们开始用 Python 进行原型设计，但我们突然意识到它显然太慢了。 因此我们决定在不同的计算层构建程序，以达到速度要求。 C++ 是最好的解决方案。
为了同时使用 python 和 c++，我们必须严格控制输入。
My team wrote an embedded software made out of C++ and Python. We decided to write basic classes and heavy computational routines in C++. We wrote logic in Python. Boost libraries as glue. Using boost is never easy, but the results is excellent. Fast and easy to modify. Using python to represent the custom needings, we are able to satisfy customers' needings realtime, changing the code using injection technics. Something really exciting! (ok, I'm a geek ;)
We started prototyping in python but we suddenly realized that it was clearly too slow. So we decided to structure the program in different computational layers, in order to reach the speed requirements. C++ was the best solution.
In order to use python and c++ together we had to keep a strict control on typing.
我曾在一家公司工作，该公司在基于 Atmel AVR32 并运行嵌入式 Linux 的嵌入式产品上使用 Python。 该固件最初是在 PC 上开发的（由于缺乏可用的硬件原型），后来转移到在交叉编译的 Python 解释器上运行的嵌入式硬件。
在设备上“实时”调试和修改源代码的能力是开发过程中的一大优势，并且节省了大量时间。 最大的缺点是 Python 解释器的速度和内存使用。
在生产固件的第一个版本之后，我们将代码的关键部分移植到了 C/C++。 移植工作非常简单，并且导致速度关键代码的几个数量级的改进（正如您所期望的）。
顺便说一句，大部分设计和生产测试代码都是用 Python 编写的，主要在 PC 上的测试工具内运行。
I worked for a company which used Python on an embedded product based around an Atmel AVR32 and running embedded Linux. The firmware was initially developed on a PC (due to lack of a working hardware prototype), then later moved to the embedded hardware running on the cross-compiled Python interpreter.
The ability to debug and modify source code "live" on the device was a big plus during development, and saved a lot of time. The big disadvantages were speed and memory usage of the Python interpreter.
Following the first release of production firmware we ported critical sections of code over to C/C++. The porting effort was quite straightforward and resulted in an improvement of several orders of magnitude on speed-critical code (as you would expect).
Incidently most of the design and production testing code was written in Python, mainly running inside a test harness on a PC.
根据我的经验，Python 传统上更多地用于桌面环境而不是嵌入式领域。 与 Python 被解释的事实相关的原因有两个：
当然，随着嵌入式系统变得更快、上市时间更短，Python将在嵌入式领域得到更多采用。
In my experience, Python has been traditionally used in desktop environments more than in the embedded field. There are two reasons, related to the fact that Python is interpreted:
Of course, as embedded systems will become faster and time-to-market shorter, Python will be more adopted in the embedded sector.