从 Keil uVision 迁出

/ 0评 / 0

It's time to make a change, for once in my life.

当我们谈到 STM32 开发的时候,我周围人的第一反应就是用 Keil uVision. 我对 uVision 的了解也就仅仅在实验课上没有其他工具可用的时候——好在,实验课的难度并不高,哪怕用记事本都能做完,所以用 Keil 仍然可以忍受。

但是当我希望做更复杂的事情的时候(比如从头编写一个 RTOS),uVision 的能力瓶颈就开始体现了。以及,我的日常工作环境是 Linux 而不是 Windows, 再叠加上这个工具是收费的,(而大多数人都直接选择破解这个软件,作为正版优越党这是不可接受的!)所以,从 uVision 迁出就成了一种必然。

选择

进行 STM32 开发并不一定需要用 uVision, 这和 8051 不同。写 8051 的时候,你只有 uVision 可以用,因为没有其他任何能用的编译器支持编译到 8051. 写 STM32 的时候,选择还是有的——GCC 工具链。

当然,基于 Eclipse 开发的 STM32 System Workbench 作为一个切换的起始点很好,因为至少你不需要手动配置一大堆工具链。和 uVision 一样,很多操作都由工具自动帮你配置好,你只需要直接开始写代码就可以了。

但是从 uVision 迁出的理由之一就是:我希望我的工程是完全由我的工程文件指导的,这样它就可以在无头环境下编译而不需要有人去点那个启动按钮。以及在菜单里面找东西?我希望尽可能地避免这种「学习工具」的依赖的产生。

况且,我的要求实际上并不高。我只是希望有一个足够聪明的编辑器而已。

CLion

有一段时间我开始用 CLion 进行开发。因为某一次更新的时候我发现 CLion 的新建工程菜单里出现了「嵌入式开发」这一行。搭配 STM32CubeMX 进行代码生成,几乎是完美的开发体验。

当然,CLion 并不会上来就给你装好工具并配置一大堆玩意,你需要自己去做。我并不反感手动进行工具链的配置,这个内容(由于在 Linux 下待了这么久)还是相对容易的。但是随之而来的问题就是团队内的其他人跟不上进展,因为团队里的其他人甚至不知道「啥,我还得自己装一大堆东西?」

就算你足够聪明、足够体贴地架设了软件部署工具,你会发现把旧的代码结构移植到新的工具链中相当耗费时间。因为之前的编译指导参数都由 Keil uVision 来管理,现在单独地捞出代码而不借助 .uvprojx 文件,你需要手动调整 CMakeLists.txt 指导编译器寻找代码、添加合适的链接脚本,以及更恐怖的:单独修复代码中每一处由于使用了 C89 标准非兼容写法产生的问题。

以及,CLion 也是一个需要购买的工具。不过至少可以用学生身份申请。但是团队里的人由于普遍的英语能力……低于你的预期,所以不能独立完成学生身份的申请。就算你终于挨个帮他们完成了申请,他们启动 CLion 的第一反应是:有没有汉化包?

也许是我个人的要求太高。CLion 的团队兼容性不足,真的要强行推广的后果就是我一个人揽下所有的活,其他人如果要干点什么还是用 uVision, 而且两端代码还不能同步或者共享了。这显然不是一个好的策略。

随着时间流逝,我的学生身份也仅仅剩下三百多天,而真的花钱购买 CLion 对于我个人而言也是一个不小的负担,所以还是要另寻他法。

VS Code

毕竟,我只是需要一个足够聪明的编辑器而已。用 CLion 也无非是为了更严格的代码审查、静态分析等等,而这些功能并不是 CLion 专有的,而是通过 CMake 配合 Clang-Tidy 完成的。CLion 专有的功能,比如代码审计、自动完成,也并非没有替代品。

好在开源社区已经有了一个新的操作系统编辑器来进行文字编辑工作。通过插件可以轻易拓展编辑器功能。而且,已经有非常多的慷慨的灵魂愿意将相关的插件发布到插件源内供所有人使用了,从 CMakeCortex-M Debug, 所有开发相关的插件都有。当然,仍然需要你自己挨个手动配置工具链和插件。

不过至少 VS Code 有一点好:它有汉化。配合软件部署工具,把它推广给团队还是在可行范围内的。

为啥

我做了,因为我可以做到。VS Code 进行 STM32 开发并不是空中楼阁——我已经用它写 SkyLab 一段时间了。

我实际上也很清楚,在之后工作中,我如果真的从事嵌入式开发的话,我肯定还得用 Keil uVision. 这似乎是徒劳,但是这一圈的折腾下来,我对 Cortex-M 架构有了更深层的认识,这种认识上的提升是其他方式难以比拟的。以及,这一圈折腾带来的关于编译的工作原理的认识使得我可以切换到任何工具链并快速开始工作,不需要再「学习新工具」。

有些时候我们仍然是需要揭开抽象层看一下的。我们在开发过程中可以借助各种工具忽略底层的细节,不过在学习过程中,好奇一下还是很必要的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注