MCU开发

作者:刘鹏
来源:恩智浦MCU加油站

本文的上半部分简单介绍了什么是Swift,为什么要用Swift做MCU的开发语言:将Swift语言应用到MCU开发中(上)。接下来将介绍作者本人在进行的一个项目,旨在开发出一个适合于MCU的Swift开发环境。

项目框架

原生Swift编译器是不支持生成Cortex-M机器指令的,但得益于LLVM框架的模块化架构,仅需少许Hack即可为其添加一个现成的Cortex-M后端。


得到了Cortex-M平台的机器指令后,代码实际已经可以在该平台上运行,但这样的空中楼阁用处并不大,Swift的很多高级特性还是需要底层基础库(libc, libstdc++)和基础算法(比如堆的管理,线程的管理)来支持。

在实践中,我们没有选择自己去实现所有的细节,而是选择了Zephyr这个新兴的RTOS来做底层支撑。下面逐层来介绍项目的框架。

硬件平台

我们的项目是一个更关注应用层开发的创意实现平台,开发者当然不能受到硬件性能的局限。因此我们选择了全球性能最强,性价比也极高的NXP i.MX RT系列MCU作为第一款开发板芯片,其核心参数如下图:


另外,我们外挂了32M SDRAM和16M Hyper Flash,板载DAPLink下载器,板载microSD读卡器。这样的硬件性能,在MCU界可以算是“顶配”了。

排母外侧引出了所有常用的外设,包括一组摄像头接口,排母内侧还有完整的RGB信号输出,无论是做热门的视觉项目或者GUI项目,硬件性能上是有充分保障的。

下面是该模组的引脚配置图:


Zephyr RTOS

在嵌入式底层的硬件世界,碎片化的现状还将持续相当长的一段时间,我们没有必要与各家芯片厂的原生API甚至寄存器较劲。

“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”,我们的解决方案便是选用了一款兼容并包,前景无限的RTOS—Zephyr


Zephyr项目是一个采用Apache 2.0协议许可,Linux基金会托管的开源RTOS项目,于2019年4月份发布了第一个长期维护版本v1.14.0。

RTOS有上百种,为什么选择了Zephyr这个新兴的RTOS?

① 跨架构,良好适应嵌入式底层硬件的碎片化。到目前为止,Zephyr一共可以支持6种架构:X86架构、ARC架构、ARM架构、NIOS II 架构、RISC V架构和Xtensa架构

② 纯C语言编写,代码框架与Linux框架类似,统一的设备驱动模型为上层提供了一致的API接口

③ 兼容POSIX标准,很容易为Swift的多线程提供底层支持

④ 不仅仅是一个RTOS,承诺了各种软件协议栈的持续加入及其可用性

⑤ 巨头的站台及活跃的社区热度,保障了项目的持续性与前景会越来越好

恩智浦i.MX RT系列芯片在Zephyr上得到了NXP官方的支持,很容易便可以将各种驱动直接拿来使用。

SwiftIO

因为有了Zephyr的支持,这一层反倒变得比较简单。


Swift可以与C无缝衔接,我们所做的仅仅是将Zephyr驱动,API用C语言打包封装,然后套上一层Swift的外壳,仅仅是简单的调用关系,没有任何复杂的戏法。

我们给这一层API框架取名为SwiftIO。

至此,开发者仅需在代码里import SwiftIO(类似C语言的#include),便可以利用其中的API来方便的操作底层硬件了。

详细的API列表可在以下站点获得:(依然在不断地更新中)

https://madmachineio.github.io/SwiftIO/

项目现状

到目前为止,该项目的Alpha版本已经进行了内部测试,预计于11月发出第一版公测硬件。

有关进一步的更新请访问网站https://www.madmachine.io/订阅邮件(网站目前也还处于建设状态...),有任何的疑问和建议,也可以发邮件到andy@madmachine.io进行交流。

作者:刘鹏
来源:恩智浦MCU加油站

围观 51

作者:刘鹏
来源:恩智浦MCU加油站

背景介绍

“你的下一个项目准备选用什么语言?”如果谁这样去问一个嵌入式工程师,可能会显得有点多余。不是只有C语言可以用来搞嵌入式开发吗?

差不多十多年前,情况的确是这样。那时候还没有一个像ARM Cortex-M这样能占据半壁江山的统一核心,嵌入式处理器碎片化极为严重。绝大多数MCU本身性能不高,各种资源都比较有限,业务模型通常也比较简单,连RTOS都用不上,直接裸奔即可解决大部分业务逻辑,嵌入式工程师绝大多数时间都在跟原厂的底层驱动作斗争。也只有C这样接近底层,各种编译链极其完善的语言才能得到所有人的认可。

随着ARM Cortex-M核的MCU逐渐占据市场主导地位, MCU的性能逐渐追上了90年代中后期的通用CPU,使用原厂提供的API来进行开发,逐渐取代了寄存器开发方式,而底层硬件的操作变得大同小异。

最近几年,随着物联网、IOT、AI这些概念越来越火热,MCU的业务模型也开始变得越来越复杂,各种通信协议栈被塞了进去,各种复杂算法被塞了进去,越来越多非EE出身的程序员、DIY爱好者也开始进入嵌入式开发领域。

市场需求

有需求就有市场,Arduino就是在这样的背景下诞生的。

一些新的开发者对MCU底层硬件细节并不关心,只想快速实现自己的想法和创意,Arduino通过C++对底层硬件进行层层包装,给最终用户提供了一套极为简洁的API。简洁到什么程度?只要稍微学习,中小学生都可以做出像模像样的作品。

尽管Arduino这种将硬件API化的开发方式让资深嵌入式工程师颇为“瞧不上”,它却实实在在地掀起了一阵变革的风向。无论业界巨头还是创新者,都开始幻想着能有一套较为统一的嵌入式开发方法。

Arm基于C++做了一套mbed框架,采用类似Arduino的简洁API,为多种Arm平台做了适配移植。

这都是一些较为传统的尝试,还有一些更为激进的极客开发者,觉得既然硬件操作都已经抽象为标准API了,我为什么还要受限于偏底层的C和让人无比困惑的C++?为什么不可以用我熟悉的语言去操作MCU?事实证明,这些想法并不是天方夜谭,以下仅列出部分现代语言的MCU操作框架:


Python: MicroPython



JavaScript: Espruino



Golang: TinyGo

Swift语言介绍


既然已经有各种新的尝试了,为什么又要多一个Swift?而且听到Swift,大家第一反应可能是“那不是Mac和iOS的专用语言吗?”

其实不然,Swift的创始人Chris Lattner对Swift愿景便是“统治世界”

它从最开始的设计就是要成为一门系统级编程语言,源代码全部开放,由社区主导开发进化。

以下仅列出一些Swift的特性:

  • Swift公布于2014年,极为年轻,无历史包袱,广泛吸收了近年各种编程语言的优势
  • 纯编译型静态语言,无GC机制,这是实时系统的必要条件
  • 支持系统级开发,直接生成对应机器码,使用ARC机制来实现内存管理,通过一个较小的开销来降低开发者的心智负担
  • 代码范式多样,支持面向对象,面向协议,函数式编程
  • 学习曲线平滑,可作为初学者的第一门编程语言
  • 语法优雅,适合各种挑剔的程序员
  • 背景雄厚,发展前景无限

综合以上特性,可以说Swift是为数不多的极其适合MCU设备的现代化语言。

另外还有一个Rust,但Rust的学习曲线极为陡峭,喜欢严厉地“虐待”开发者来保证代码的正确性,这又有悖于我们简化MCU应用层编程的初衷。

其余绝大多数现代化语言中,要么带有嵌入式中绝对不能接受的GC机制,要么为解释性语言,效率极低(即便如此,MicroPython的应用场景还是越来越丰富,说明大家对易用性的需求越来越强烈)。

相信随着时间的推移,Swift在嵌入式上的可用性会逐渐完善。

下期预告

恩智浦的i.MX RT系列,已经把Cortex-M为核心的MCU的性能提高到了很高的水平,可以允许在她上面开发更高级的编程语言。

本文下期将介绍在i.MX RT1050上实现的对Swift语言支持的软硬件框架,并将预告公测的计划。

作者:刘鹏
来源:恩智浦MCU加油站

围观 87
订阅 RSS - MCU开发