MicroPython 的优势

定位的场景

MicroPython 在设计上最初就是为了嵌入式微处理器运行,例如在 nRF51822 (256kB flash + 16kB RAM) 的芯片上也可以运行起来,也有人肾得慌在 STM32F103 上跑起来了,从代码上来看 Python 函数栈的官方默认是 16K RAM,也就意味着它可以在许多微芯片上提供一个最小的 Python 代码交互环境,但这并不包含它们的拓展功能,毕竟编译更多的功能代码意味着需要更多的 Flash 或 外部存储。

高度与宽度

根据定位的场景我们可以看到 MicroPython 在硬件的深度可以去到超低功耗芯片开发领域,而采用 Python 语言的开发方式决定了它的软件宽度可以站在全世界热门的 Python 领域中进行借鉴和参考,这带来了许多改变,如改变以往的硬件测试流程和开发流程,改变一贯认为的硬件程序开发困难的刻板印象,这个现象之后会详细阐述。

同类开发环境一览

我(?)以正在开发的 BPI:BIT(ESP32) 为例,对应的同类解释器或 SDK 源码相关开发环境有:

  • Arduino(C++)
    • 基于 C++ 代码设计
    • 拥有和 C 兼容的优势,可以无缝接入 ESP-IDF 。
    • 大量遗留的代码库可以直接整合使用。
    • 近年来的提供的外设硬件库质量大幅度下降,导致硬件开发后的稳定性欠缺。
  • Javascript
    • 常见于 Ruff lite 、 JerryScript 等。
    • 新生事物,同 MicroPython 相似的结构
    • 支持 JS 异步驱动事件模型,要求芯片必须拥有系统(RTOS)。
    • 在硬件上使用浏览器形式的开发方式
    • 硬件驱动相关支持库较弱,基于此深耕硬件接口的开发者不多。
    • 相关的开发资料和代码还不够稳定。
  • lua
    • 相比 MicroPython 和 JerryScript 它的可移植性要来得更为简单一些。
    • 如仓库:https://github.com/whitecatboard/Lua-RTOS-ESP32
    • 但由于 lua 是小众语言,地位和 bat 、 bash 差不多。
    • 所以不是在开发应用领域里不是很流行,但作为自动化脚本工具还是很棒的。
    • 开发资料相关周边的基本没有,会 lua 的大多都是孤芳自赏,比如我(大概)。
  • ESPEasy
    • 大概算是一种开发环境,类似于路由器系统(openwrt)
    • 除了好玩,就没有什么用了。
    • 像这样的固件还有很多很多,在这里就不一一举例了。
  • esp-idf
    • 硬件开发芯片原厂一般都会提供的 SDK ,esp32 提供的多为 esp-idf 、esp-adf 、 esp-mdf 诸如此类,对应的 stm32 的 hal 或 CC25XX stack 等等原生 C 代码 SDK 。
    • 上述开发环境均基于此继续开发得来的产物。

经过了上述的各类开发环境的初步认识,我们就来说说 MicroPython 对比后的优劣吧。

MicroPython 的优劣

我们不难看到,MicroPython 和 Python 一样,发挥了胶水语言的优势,最大化的兼容和保持了各自的优势,减少自己的劣势。

在动态语言大战中,MicroPython 保留了面向过程、对象、切面、函数的编程语法,丰富的开发方式带来了代码的开发广度,反观 lua 从语法上砍掉了大量开发常用的语法糖,大幅度的裁剪代码量,在开发者开箱即用的角度来看, MicroPython 迎合了大多数开发者的拿来主义(我?)。

与 JavaScript 相比的 Python 在性能上没有太多的优势,唯一的优势就是 Js 的编程思维并不适合长期浸染在面向过程领域里的 C 语言硬件编程,例如串口收发这样简单的一件事情,在 Js 的异步事件绑定模型下,需要设置一些回调函数等待处理,而在 MicroPython 中,通过多线程可以实现 Js 的效果,但没有多线程也可以通过 While 死循环轮询或非阻塞状态机来实现同样的功能,而后者的死循环就是嵌入式 C 中的常见编程习惯了,但在 JS 的硬件编程中,某个函数若是发生了死循环,那真的是一种灾难,所有的后台线程都无法运行了,但死循环这样的开发方式真的太烂了,建议硬件开发的时候多写异步驱动代码,或者是状态机代码,以提高 IO 性能。

因此 MicroPython 在众多动态语言中与 C 语言的兼容性为最佳,在程序设计上也是如此,向下兼容语言的同时又吸取了上层优秀代码的精髓,尤其是异常机制和动态类型。

此时相比 C 或 C++ 语言,MicroPython 牺牲了一些执行性能,平均每段 Python 代码回到 C 的执行函数操作额外增加了 5 us 左右,这是我在写软串口的时候发现的,但也带来了解释器接口(其他动态语言也是如此),通过动态调整执行接口的参数,加速了硬件程序的验证与开发。

在面对硬件程序的主控方面的开发,经常面对大量的硬件 API 通信调试,就像调试网络服务里的 HTTP API ,对硬件里的 UART 、I2C 、 SPI 、RS485、CAN 等等从机设备的控制,使用 MicroPython 进行开发验证,要比纯粹使用 C 、Arduino 来的更为迅速,毕竟它们编译一次 2 分钟,运行 10 秒,而 MicroPython 烧录 2 分钟,之后每隔 5 秒运行反复运行,这也得益于 MicroPython 的硬件外设驱动的开发相当可靠和稳定(其实是 ESP-IDF 稳定可靠的原因 XD )。

所以别人花一天调试的硬件接口,我几个小时就可以调试得七七八八了,尤其是多机协议的反复测试接口,例如: Modbus readaddr 或是 I2C.scan 这类接口。当然,上述的这种开发哪怕是封装成 AT 指令的接口方式也可以做到,但在 Python 解释器的基础上可以编写更多复杂的后续逻辑操作,而非 AT固件的指定接口形式调试。

综上所述, MicroPython 的硬件开发地位处于硬件开发的初期验证和原始开发阶段,在后期大多都会转回 C ,而软件领域里,则有大量的逻辑示例代码供硬件开发调用和测试,对于硬件开发人员,将会获得更多控制硬件的方法,对于软件人员也会更容易的配合硬件人员开发硬件和调试硬件。

结语

如果你有其他更多的见解,欢迎一同探讨和分享。

  • 撰写时间:2019年9月2日
  • 作者名称:junhuanchen
  • 联系方式:
  • WeChat & Github: 作者名称
  • QQ & E-mail: 作者名称@qq.com

转载于:https://www.cnblogs.com/juwan/p/11445828.html

你可能感兴趣的:(python,硬件开发,lua)