我们用rust开发的新版产品刚刚交付，已经在海上安装测试完毕并顺利投产。终于松了口气，同时也有时间和精力来做个全面的总结了。
这个产品，目前差不多有三版：
- 第一个版本是用c+rt-thread写的，投产后出了一个内存泄露的bug，由于我们的产品是安装到海上，bug修复了也很难更新到产品上，最后穷尽洪荒之力才找出对策进行了处置【不是排除】，但现在依然象个定时炸弹一样悬在那。导致我对c失去信心，最终下定决心换用rust
- 第二个是用rust写的demo版本，是基于RTIC框架写的。后因认为RTIC框架的限制比较大，在写完主体功能后就废弃了
- 第三个版本就是基于Embassy框架写的这一刚交付的版本
ps：海上的情况太过复杂，很多情况是我们现在的测试环境无法完全模拟的
本文即是基于笔者开发这三个版本的经验，对rust嵌入式的开发所做的一个阶段性的总结。
开发门槛高 vs 现场智能化
就嵌入式来说，rust+Embassy vs c+rt-thread的门槛是两个级别。
我是java和python的系统工程师，开发第一个版本时，就没用过c，也没开发过嵌入式！但花了一个月的时间，第一个版本就写完了。
开发第三个版本时，有了第一个版本的所有设备功能的开发经验，有第二个版本的rust尝试，但总的开发时间是从年后到5月下旬，合到三个月了。
当然，这里面主要的原因有两个：
1、rust在嵌入式方面的生态没有c这么成熟：有rt-thread这样的RTOS。虽然Embassy也比较成熟了，但它不是一个完整的RTOS，需要花大量的精力来开发一些较为底层的功能部件，如之前介绍过的数据锁：rust嵌入式开发之基于await构造应用级临界区。
当然，如果只是如多数嵌入式的应用场景那样的话，用RTIC框架完全可以：rust嵌入式开发之RTICvsEmbassy，那就简单很多了。但如我上面那篇文章所述，RTIC框架能力有限，起码对我司来说的是不够的：
- 我们需要连接大量各厂家的设备，串口之多以至于只能用10串口的STM32F403VG，每种设备的协作机制完全不同，所以就需要强大的异步协作能力，RTIC就没有提供异步支持
- 海上工程的特殊性，决定了我们必须提供多种的错误恢复手段，RTIC太弱
2、除了第一版中通常的现场操控能力之外，在新版中我还开发了额外的应用能力，如命令行，这相当于在做RTOS中的shell了，所以本质上还是rust嵌入式的生态还不够成熟的问题。
第一个版本是以在服务器上抄收到现场数据为完工标志，但海上施工非常困难，出海时一切正常，突然瓢泼大雨的再正常不过了，所以有必要提供现场的检查手段，因此需要提供命令行功能。
其它还有debug、对象锁之类。
这也是我坚持认为，随着MCU的资源越来越丰富，嵌入式编程必然会走向复杂化、应用化的原因：为了在竞争中获胜，现场器件越来越智能化是必要的、必须的趋势！
如我们现在就在考虑海上碰撞的预警、检测与证据固定，已经在进行功能方面的论证。
也正是基于这个判断，我才会坚定的抛弃c而拥抱rust。
概要之，如果只是瞄准目前通常的嵌入式应用场景：固定功能的现场操控。其实没必要用rust嵌入式编程【rust+RTIC功能有限又自带rust的高门槛，完全属于自找麻烦】，门槛太高、成本也高出很多；开发周期【尤其是产品成型的第一个版本的开发周期】太长，可能会导致产品验证出现问题。
但是，如果希望提高竞争水准、抬升行业准入门槛，并将其中一个发力点落在现场感知、反应的智能化能力上，我认为除非有极深的积累，否则rust嵌入式自然拥有相当强的竞争力，毕竟c太古老了，不太适合快速低成本开发高可靠、高价值的应用。
对冲rust的高门槛
rust门槛高、心智负担重，这是公认的rust的缺点。但就嵌入式而言，这个缺点其实是不存在的。
原因非常简单，嵌入式再如何复杂，现在也远比后台应用简单的多，所以完全可以采取措施来对冲rust的高门槛：
1、用静态变量互斥访问来对冲rust的生命周期、借用难
对rust的生命周期、借用，作为初学者的我也很头疼，而我的解决办法非常粗暴：
嵌入式的应用场景简单，所以我直接把主要功能所需要的数据静态化、然后进行包裹、再用互斥锁进行保护，这样一来，所有的操作接口都是：&'static self。
这就完全不再需要考虑生命周期和借用的问题了，编程难度直线下降，编译器一声都不敢吱:)
这个方法在上线后，轻松抗住了一天40万条数据的采集压力！而且经过计算，还远没到设备极限，大家可以放心大胆的用:)
2、用资源的高耗费来对冲编程的复杂度
既然现在MCU的资源极大的丰富了，堆资源就好，绕开死磕技术难度的坑就是了。
就如我们的串口读取，底层申请了内存，上层应用什么时候用完、需要进行释放是不清楚的，而且串口读取到的数据，还可能流经多种功能模块，比如用蓝牙模块以modbus协议读取设备数据，就需要流经串口模块、蓝牙模块、modbus模块、应用模块。这对内存管理就带了很大的压力。
所以我同样是用简单粗暴的方法来应对：每层自己申请自己释放，要提交给上层的，就做一次内存copy。
这样过一层就做一次内存copy的资源耗费显然太过巨大，但这样简单啊，硬怼资源就很容易实现，反正内存copy那点开销相比现在的MCU和嵌入式场景实在不值一提。
这个以资源开销来换简化编程、消弭bug的方法在我们多个串口、多种设备管控，一天40多万条数据的采集、海上无线传输的压力下工作良好！
一句话：在目前的情况下，rust嵌入式编程不需要考虑优化、不需要担心浪费，堆资源是最应优先考虑的方案。
在我来看，对一个产品来说，有两个指标是决定性的：
- 关键需求的满足度
- 产品的稳定性
前者是客户花钱的理由 ，rust的现代性和良好生态是支撑我们依托智能化产品来提升核心竞争力的利器，自然就是选择rust的最大理由；后者是客户付钱的理由，rust写出的程序天然自带的健壮性和可靠性，就是选择rust的第二大理由。
当然，rust在嵌入式方面的生态还有所不足，但这只是时间问题，总要给新生儿成长的时间。
谁都有缺点，弥补缺点就需要成本。借用工程技术手段和高资源开销来弥补rust的缺点，就是我们目前必要的成本。
现在看下来，这些成本完全可以接受。
rust嵌入式的不足
生态、生态、生态。这必须是rust嵌入式的最大不足。尤其是在芯片国产替代的当下，国产芯片在rust嵌入式方面的投入基本可以忽略。
如我们第一版用的就是国产的GD32，但在看好rust嵌入式的前景之后，由于芯片厂商等在基础设施方面的投入不足，最后只好又选了STM32。
当然，我相信国内的芯片厂家既然提供了这么强大的MCU，最终一定是需要软件来消耗掉这些资源的，我们的新版本已经消耗掉了384K的Flash，还有很大空间值得挖掘:)
而这要靠c肯定不现实，最终还是要在rust上发力的。只是需要提提速啊:(
rust嵌入式在生态方面的最大不足，对我们来说，自然就是缺乏一个如国产的rt-thread这样的国产RTOS。由于缺了不少必要的基础部件，就需要自己来开发，这相当于提升了开发门槛和成本。
rust嵌入式的第二个不足，就是no_std和std的隔离。这就导致rust的良好生态在嵌入式方面被大幅度的削弱了。
比如：我在命令行中原本要实现参数的核验，但rust工业标准的正则表达式crate在no_std下就用不了，只好用了可以支持no_std的regex-automata，但用下来总感觉有些问题，由于时间太紧张了，实在无法全面测试，最后干脆就先取消了命令行的参数核验能力。
就目前来说，no_std的问题还影响不大，但随着现场智能化诉求的提升，这个问题势必会带来越来越大的限制。
第三个不足应该是rust的不足，就是IDE在编辑界面无法自动扩展宏。
我选择rust的一个重要理由，就是相比c中的宏，rust的过程宏异常的强大：完全可以媲美java中的反射和python中的@修饰符，关键还是零开销 ：rust嵌入式之用类函数宏简写状态机定义。
在java和python中我都自己实现了ORM、状态机等，所以我深知反射技术是各种框架的基础，对现代软件工程和编程技术具有无与伦比的巨大意义，当然，还有所要花费的巨大开销。
在rust中，我同样用过程宏实现了状态机、命令行、debug、控制台、串口/pwm等接口操作的自动扩写、扩展对象锁、命令-期望等等。
对rust的过程宏，我实在是太满意了。
但是，宏用得太多，某些利用宏扩写出来的技术细节我自己也就记不清楚了，当需要探究某个技术细节的时候，IDE竟然不给自动展开所扩写的代码，还需要手动执行命令来展开宏，然后去另外的文件中来查看，非常低效。
这个不足，在排错的时候尤其讨厌！
结语
虽然rust嵌入式有着种种的不足，但我依然相信rust在嵌入式领域前程远大。