东莞做网站建设公司,cms影视源码采集,用织梦怎么做网站,软件开发的三个阶段RTIC和Embassy是目前rust嵌入式开发中比较热门的两个框架。本来呢#xff0c;针对RTIC的移植已经完成了一小半#xff0c;但在移植过程中感受到了RTIC的不足#xff0c;正好跳出来全面考察下embassy#xff0c;本文就是根据目前的尝试结果做个对比总结。
RTIC和Embassy是两…RTIC和Embassy是目前rust嵌入式开发中比较热门的两个框架。本来呢针对RTIC的移植已经完成了一小半但在移植过程中感受到了RTIC的不足正好跳出来全面考察下embassy本文就是根据目前的尝试结果做个对比总结。
RTIC和Embassy是两种完全不同的思路
1、RTIC是基于MCU强大的中断体系以中断来驱动所以RTIC的重心是放到了数据的隔离上可参考rust嵌入式开发补充整个框架不管是处理还是规模都比较简单
2、Embassy则是基于rust语言的异步特性【async和await】、Send等来实现线程化并确保安全
也就是说一个依托底层MCU一个依托rust语言所以分别形成了自己的特色。
RTIC的优缺点
RTIC的优点就是简便一旦理解了RTIC的工作机制开发起来只要牢记三个方面就好了
中断驱动所有的任务调用源头都是某个硬件中断是天然的事件-响应模型以此模型来编写各个处理任务然后将这些任务分配到相应的硬件中断中spawn就好了逻辑非常清晰、简洁数据隔离RTIC将数据分为了本地和共享两类本地数据为某个任务独享其它任务全都无法访问共享数据为指定的某几个任务共享使用时需加锁来互斥使用。确保了数据安全而且数据的访问逻辑也非常清晰不容易混乱使用上也非常简单不会出现复杂的OptionArcMutex…的形式【RTIC自己做了提供给用户任务时就是复制过来的数据指针了】优先级RTIC依靠MCU进行任务的调度而MCU不管其它只依靠中断许可和优先级进行调度。所以优先级就是RTIC工作的基石如果用户任务较多就需要仔细考虑这些任务的调配和优先级的匹配问题
RTIC的缺点就是过于简单对rust的特性支持不够面对稍微复杂点的任务就有些力不从心了。
首先上面讲了RTIC良好的数据隔离机制但反过来由于用户任务中的数据都来自RTIC从自己所管理的全局数据中的复制所以RTIC的用户任务中很难使用闭包因为其所有的数据都是从栈上分配的一旦离开所在用户任务就会被销毁而RTIC中所有任务都是中断驱动。这两点决定了RTIC中的闭包无法异步使用但不能脱离本地来异步使用的闭包一点价值都没有的。
而如果自己用box来保存与复制那何不干脆另起一个用户任务呢
但每个RTIC的用户任务的参数都是通过宏扩写出来的所以用户任务很难通过指针的方式按需调度这对状态机、控制台命令、远程控制等功能很不友好。
也就是说RTIC最大的问题就是不灵活一旦需要灵活的根据实际情况来动态调用用户任务RTIC就会很笨拙。需要通过静态函数和统一的参数表来为用户任务的调用提供参数转换和过渡。这对于状态机还好但对于控制台命令和远程控制就很不友好了。
其次RTIC是用过程宏来完成规模庞大的任务和数据的扩写工作的【对rust的过程宏还不太理解的可参考rust嵌入式之用类函数宏简写状态机定义】但由于其对过程宏的重度使用使得我们编写自己的过程宏然后和RTIC进行衔接时就不能触碰所有的数据和用户任务只能通过上面提到的静态函数来进行过渡。
而这自然就会大幅度的削弱过程宏的强大与便利了。
Embassy的优缺点
Embassy我才刚开始尝试所以就只能对比上面RTIC的优缺点来说了。
1、Embassy既然是依托rust的async和await来调度任务所以其必须实现自己的一个运行时来完成中断接管、poll登记与分发、基于优先级的任务调度等等
运行时的存在自然会提供更好的灵活性和弹性更有利于充分发挥rust作为现代语言的优势与强大。
2、Embassy提供了强大的线程间通信手段如Channel和mbox这就非常便于复杂业务场景下各功能部件之间的密切协作了
3、任务的创建手段更灵活、更便利如
方式一独立任务模式
#[embassy_executor::task]
async fn writer(mut tx: UartTxstatic, USART1, DMA1_CH4) {#串口1通过一个Channel接收要发送的字符串然后以DMA方式发送loop {let buf CHANNEL.receive().await;unwrap!(tx.write(buf.as_bytes()).await);}
}
在主程序中启动该任务
unwrap!(spawner.spawn(writer(tx)));
如此不管在哪只要通过Channel发送字符串就可以执行
CHANNEL.send(s).await;方式二闭包模式
//主程序中定义一个闭包
let blinky async {loop {//注意这里直接使用了主程序创建的led和delay两个局部变量【rust会自动将其分配到堆上去】//其它闭包也可以使用这两个变量【对于没有实现Copy的需要考虑借用问题】//当然如果多个闭包同时使用到某个复杂的数据结构需要实现Send或用Mutex等实现线程间数据保护led.toggle();Timer::after_millis(delay).await;}
};
//将这个闭包启动
futures::join!(blinky, ...其它闭包...);RTIC可以同样很简单的实现方式一但根本无法实现方式二。而对于大量简单的小任务来说显然方式二更简便同时还省去了RTIC中复杂的数据隔离措施更轻更快。
此外Embassy对过程宏的使用不是太过严重甚至还可以在Embassy项目中支持RTIC框架结合其对闭包的友好支持我们完全可以在用过程宏来定义状态机、控制台命令时直接用闭包来实现动作或命令的实现函数既省去了过渡函数的繁琐还更容易阅读与理解降低了bug的几率。
当然Embassy不提供如RTIC般的数据隔离与保护所以线程间的数据保护就需要程序员自己来承担了。
总结
如开头所述RTIC其实是一种中断驱动的嵌入式任务调度思想的rust实现【增强了数据隔离与保护】而Embassy则是rust语言用于嵌入式环境的一种实现【所有其有两个发力点运行时和基于自己HAL的各种芯片的适配】。
显然RTIC更容易上手更针对固定功能的嵌入式开发而Embassy更有rust味道更灵活、更强大给予了程序员更丰富的支持同时也对程序员提出了rust特有的高要求、高门槛。
当然rust嵌入式开发还有tock在Embassy之前笔者也是更看好tock但仔细研究了几天笔者认为就嵌入式来说tock属于过度设计了
资源占用过于庞大flash需256K起ram需64K起对于大多数的嵌入式应用来说实无必要tock的一个诉求是彼此隔离所以安全的app但对于嵌入式来说实在有些过分了
所以tock是针对一个复杂产品的中控来设计的。由于我们目前尚无此需求所以我们显然不是tock预期中的目标群体。因此很快就转向Embassy了。
