[讨论] RT-Thread_MicroPython和单纯的MicroPython相比有什么优势？

最近移植了RTT-MPY在stm32f103zet6_144Pins上的工程，在任务中通过设置python 命令入口实现上电自动运行python命令，使用MicroPython的优势在于对于python的兼容和大量的支持库，能够在关心更少硬件知识的同时进行嵌入式开发，主要还是极客/玩家来进行玩耍的东西，但最近一时间蔚然成风。。。在资源极为有限的嵌入式设备上跑M_python作为产品几乎是不可能的事情，据说python运行效率比c慢了10倍不止，作为一个嵌入式专业的研究生也是作为一个发论文的热点来关注Mp的发展，突然我发现了一个问题，RTT_MicroPython相比于MP又有什么优势呢？[color=rgba(0, 0, 0, 0.87)]由于RTT[color=rgba(0, 0, 0, 0.87)]操作系统提供了很好的POSIX[color=rgba(0, 0, 0, 0.87)]标准支持，所以MP_Lib[color=rgba(0, 0, 0, 0.87)]中很多模块可以在RTT_MP[color=rgba(0, 0, 0, 0.87)]上运行。目前在RTT_MP的MP环境下支持操作系统的多少API呢？请教各位大神一起来学习进步~

在高端ARM怎么玩都没问题，如果一般的MCU还老实实用C比较实用^_^

在哪里跑他都跑不过C的速度这是肯定了，看中的应该是他的快速开发和兼容性吧

嗯，挺好的

我来总结下吧

1、开发板适配的角度：

• 原生的 MicroPython ：只是对官方自己的开发板支持的非常良好，想要用非官方的板子来跑 MicroPython 就需要自己从头折腾底层的移植。
• RT-Thread MicroPython：只要是 RT-Thread 支持的板子，有一定资源，都能跑 RT-Thread 版本的 MicroPython ，很大程度上降低了 MicroPython的门槛。
  

2、驱动适配的角度：

• 原生的 MicroPython ：如果花了精力，让原生 MicroPython 在自己板子上跑起来，但接下来的驱动适配（Pin/Uart/I2C/SPI等等）工作，第一次搞的话，又会有一大堆坑迎面而来。
• RT-Thread MicroPython：RT-Thread 支持设备驱动框架，只要是 RT-Thread 支持的板子集成了对应的设备驱动，上层 Python 都可以直接调用，省时又省力。
  

3、二次开发的角度：

• 原生的 MicroPython ：有了 MicroPython 后虽然上层能实现 Python 开发，但不可能避免的项目里的有些功能确实是目前的 MicroPython 不支持的，而且只能用 C 来实现。此时就需要修改 MicroPython 源代码，熟悉官方的软件框架，大部分还是裸机模型，这些都会是比较吃力的工作。
• RT-Thread MicroPython：而 RT-Thread 支持众多 C 的可重用组件，软件包数量目前已经突破 50+ 了，你想要的功能几乎是都能找到，配合图形化的开发工具，二次开发的难度一下子就降低下来了。
  

4、多线程的角度：

• 原生的 MicroPython ：官方那边只是很少的 Board 支持多线程，如果自己动手来开发，门槛还是相当高的。
• RT-Thread MicroPython：RT-Thread 属于 RTOS ，原生就支持多线程。上层的 Python 多线程接口跟 Python 官方也都是保持一致的。
  

5、社区生态的角度：

• 原生的 MicroPython ：官方在国外生态还是不错的，可是语言门槛、距离门槛，会让我们国内开发者感觉跟官方的距离还是挺远的。
• RT-Thread MicroPython：RT-Thread 作为国内最大的嵌入式开源社区，活跃度非常高。RT-Thread 也专门编写的了 《RT-Thread MicroPython 开发手册》，由浅入深的角度带大家一起玩 MicroPython。针对常见的开发板还提供了下载即用的固件，论坛也有专门的 MicroPython 版块，里面还有很多学习资源。
  

RTT不错，希望可以继续推动micropython的应用。